Search Results

Search found 3489 results on 140 pages for 'tcp'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 10/140 | < Previous Page | 6 7 8 9 10 11 12 13 14 15 16 17  | Next Page >

  • [tcp] :/: RPCPROG_NFS: RPC: Program not registered

    - by frankcheong
    I tried to share the root / from a fedora 9 to a freeBSD while when I tried to mount the / folder it complained with "[tcp] nfs_server:/: RPCPROG_NFS: RPC: Program not registered". I followed the below steps to setup on the fedora nfs server:- Add the below line inside the /etc/exports / nfs_client(rw,no_root_squash,sync) restart the nfs related service service portmapper restart service nfslock restart service nfs restart export the filesystem using the below command:- exportfs -arv On the nfs client, I have troubleshoot using the below command:- rpcinfo -p nfs_server program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 32816 status 100024 1 tcp 34173 status 100011 1 udp 817 rquotad 100011 2 udp 817 rquotad 100011 1 tcp 820 rquotad 100011 2 tcp 820 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 32818 nlockmgr 100021 3 udp 32818 nlockmgr 100021 4 udp 32818 nlockmgr 100005 1 udp 32819 mountd 100005 1 tcp 34174 mountd 100005 2 udp 32819 mountd 100005 2 tcp 34174 mountd 100005 3 udp 32819 mountd 100005 3 tcp 34174 mountd showmount -e nfs_client Exports list on nfs_server: / nfs_client What else did I missed?

    Read the article

  • Why change net.inet.tcp.tcbhashsize in FreeBSD?

    - by sh-beta
    In virtually every FreeBSD network tuning document I can find: # /boot/loader.conf net.inet.tcp.tcbhashsize=4096 This is usually paired with some unhelpful statement like "TCP control-block hash table tuning" or "Set this to a reasonable value." man 4 tcp isn't much help either: tcbhashsize Size of the TCP control-block hash table (read-only). This may be tuned using the kernel option TCBHASHSIZE or by setting net.inet.tcp.tcbhashsize in the loader(8). The only document I can find that touches on this mysterious thing is the Protocol Control Block Lookup subsection beneath Transport Layer in Optimizing the FreeBSD IP and TCP Stack, but its description is more about potential bottlenecks in using it. It seems tied to matching new TCP segments to their listening sockets, but I'm not sure how. What exactly is the TCP Control Block used for? Why would you want to set its hash size to 4096 or any other particular number?

    Read the article

  • Exploring TCP throughput with DTrace

    - by user12820842
    One key measure to use when assessing TCP throughput is assessing the amount of unacknowledged data in the pipe. This is sometimes termed the Bandwidth Delay Product (BDP) (note that BDP is often used more generally as the product of the link capacity and the end-to-end delay). In DTrace terms, the amount of unacknowledged data in bytes for the connection is the different between the next sequence number to send and the lowest unacknoweldged sequence number (tcps_snxt - tcps_suna). According to the theory, when the number of unacknowledged bytes for the connection is less than the receive window of the peer, the path bandwidth is the limiting factor for throughput. In other words, if we can fill the pipe without the peer TCP complaining (by virtue of its window size reaching 0), we are purely bandwidth-limited. If the peer's receive window is too small however, the sending TCP has to wait for acknowledgements before it can send more data. In this case the round-trip time (RTT) limits throughput. In such cases the effective throughput limit is the window size divided by the RTT, e.g. if the window size is 64K and the RTT is 0.5sec, the throughput is 128K/s. So a neat way to visually determine if the receive window of clients may be too small should be to compare the distribution of BDP values for the server versus the client's advertised receive window. If the BDP distribution overlaps the send window distribution such that it is to the right (or lower down in DTrace since quantizations are displayed vertically), it indicates that the amount of unacknowledged data regularly exceeds the client's receive window, so that it is possible that the sender may have more data to send but is blocked by a zero-window on the client side. In the following example, we compare the distribution of BDP values to the receive window advertised by the receiver (10.175.96.92) for a large file download via http. # dtrace -s tcp_tput.d ^C BDP(bytes) 10.175.96.92 80 value ------------- Distribution ------------- count -1 | 0 0 | 6 1 | 0 2 | 0 4 | 0 8 | 0 16 | 0 32 | 0 64 | 0 128 | 0 256 | 3 512 | 0 1024 | 0 2048 | 9 4096 | 14 8192 | 27 16384 | 67 32768 |@@ 1464 65536 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 32396 131072 | 0 SWND(bytes) 10.175.96.92 80 value ------------- Distribution ------------- count 16384 | 0 32768 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 17067 65536 | 0 Here we have a puzzle. We can see that the receiver's advertised window is in the 32768-65535 range, while the amount of unacknowledged data in the pipe is largely in the 65536-131071 range. What's going on here? Surely in a case like this we should see zero-window events, since the amount of data in the pipe regularly exceeds the window size of the receiver. We can see that we don't see any zero-window events since the SWND distribution displays no 0 values - it stays within the 32768-65535 range. The explanation is straightforward enough. TCP Window scaling is in operation for this connection - the Window Scale TCP option is used on connection setup to allow a connection to advertise (and have advertised to it) a window greater than 65536 bytes. In this case the scaling shift is 1, so this explains why the SWND values are clustered in the 32768-65535 range rather than the 65536-131071 range - the SWND value needs to be multiplied by two since the reciever is also scaling its window by a shift factor of 1. Here's the simple script that compares BDP and SWND distributions, fixed to take account of window scaling. #!/usr/sbin/dtrace -s #pragma D option quiet tcp:::send / (args[4]-tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 / { @bdp["BDP(bytes)", args[2]-ip_daddr, args[4]-tcp_sport] = quantize(args[3]-tcps_snxt - args[3]-tcps_suna); } tcp:::receive / (args[4]-tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 / { @swnd["SWND(bytes)", args[2]-ip_saddr, args[4]-tcp_dport] = quantize((args[4]-tcp_window)*(1 tcps_snd_ws)); } And here's the fixed output. # dtrace -s tcp_tput_scaled.d ^C BDP(bytes) 10.175.96.92 80 value ------------- Distribution ------------- count -1 | 0 0 | 39 1 | 0 2 | 0 4 | 0 8 | 0 16 | 0 32 | 0 64 | 0 128 | 0 256 | 3 512 | 0 1024 | 0 2048 | 4 4096 | 9 8192 | 22 16384 | 37 32768 |@ 99 65536 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 3858 131072 | 0 SWND(bytes) 10.175.96.92 80 value ------------- Distribution ------------- count 512 | 0 1024 | 1 2048 | 0 4096 | 2 8192 | 4 16384 | 7 32768 | 14 65536 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1956 131072 | 0

    Read the article

  • mount.nfs: access denied by server while mounting (null), can't find any log information

    - by Mark0978
    Two ubuntu servers: 10.0.8.2 is the client, 192.168.20.58 is the server. Between the 2 machines, Ping works, ssh works (in both directions). From 10.0.8.2 showmount -e 192.168.20.58 Export list for 192.168.20.58: /imr/nfsshares/foobar 10.0.8.2 mount.nfs 192.168.20.58:/imr/nfsshares/foobar /var/data/foobar -v mount.nfs: access denied by server while mounting (null) Found several things online, tried them all and still can't find any log information anywhere. On the server: [email protected]:/var/log# cat /etc/hosts.allow sendmail: all ALL: 10.0.8.2 /etc/hosts.deny is all comments How can I get a trail of log statements to figure this out? What does it take to get some logging so I have some idea of WHY it won't mount? On the server: [email protected]# nmap -sR RPC 192.168.20.58 Starting Nmap 5.21 ( http://nmap.org ) at 2012-07-04 21:16 CDT Failed to resolve given hostname/IP: RPC. Note that you can't use '/mask' AND '1-4,7,100-' style IP ranges Nmap scan report for 192.168.20.58 Host is up (0.0000060s latency). Not shown: 988 closed ports PORT STATE SERVICE VERSION 22/tcp open unknown 80/tcp open unknown 111/tcp open unknown 139/tcp open unknown 445/tcp open unknown 902/tcp open unknown 2049/tcp open unknown 3000/tcp open unknown 5666/tcp open unknown 8009/tcp open unknown 8222/tcp open unknown 8333/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 3.81 seconds From the client: [email protected]:~$ nmap -sR RPC 192.168.20.58 Starting Nmap 5.21 ( http://nmap.org ) at 2012-07-04 22:14 EDT Failed to resolve given hostname/IP: RPC. Note that you can't use '/mask' AND '1-4,7,100-' style IP ranges Nmap scan report for 192.168.20.58 Host is up (0.73s latency). Not shown: 988 closed ports PORT STATE SERVICE VERSION 22/tcp open unknown 80/tcp open unknown 111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000) 139/tcp open unknown 445/tcp open unknown 902/tcp open unknown 2049/tcp open nfs (nfs V2-4) 2-4 (rpc #100003) 3000/tcp open unknown 5666/tcp open unknown 8009/tcp open unknown 8222/tcp open unknown 8333/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 191.56 seconds

    Read the article

  • Cocoa NSStream TCP connection to FTP

    - by Chuck
    Hi, I'm new to Cocoa, but not to programming. Recently I decided I wanted to write a FTP client for Mac, and so I first made it in the language I'm most comfortable in (on Windows), and then moved on to Cocoa when I had the workings of FTP communications down. My question is (apparently) a bit controversial: How do I establish a read/writeable connection to (a ftp server)? What I have so far (non working obviously): NSInputStream *iStream; NSOutputStream *oStream; NSHost *host = [NSHost hostWithAddress:@"127.0.0.1"]; [NSStream getStreamsToHost:host port:3333 inputStream:&iStream outputStream:&oStream]; // ftp port: 3333 [iStream retain]; [oStream retain]; [iStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; [oStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; [iStream setDelegate:self]; [oStream setDelegate:self]; // which is not implemented apparently [iStream open]; [oStream open]; // .... [iStream write: (const uint8_t *)buf maxLength:8]; Which is partially based on http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Streams/Articles/NetworkStreams.html Now, why have I chosen NSStream? Because while this question is merely about how to connect to a FTP stream, my whole project will also include SSL and as far as I've been able to search here and on google, NSStream is capable of "switching" to a SSL connection. I've not been able to see the connection being made (which I'm usually able to do), but I also heard something about having to write to the stream before the stream will open? Any pointers are greatly appreciated, and sorry if my question is annoying - I'm new to Cocoa :)

    Read the article

  • Flush kernel's TCP buffer with `MSG_MORE`-flagged packets

    - by timn
    send()'s man page reveals the MSG_MORE flag which is asserted to act like TCP_CORK. I have a wrapper function around send(): int SocketConnection_Write(SocketConnection *this, void *buf, int len) { errno = 0; int sent = send(this->fd, buf, len, MSG_NOSIGNAL); if (errno == EPIPE || errno == ENOTCONN) { throw(exc, &SocketConnection_NotConnectedException); } else if (errno == ECONNRESET) { throw(exc, &SocketConnection_ConnectionResetException); } else if (sent != len) { throw(exc, &SocketConnection_LengthMismatchException); } return sent; } Assuming I want to use the kernel buffer, I could go with TCP_CORK, enable whenever it is necessary and then disable it to flush the buffer. But on the other hand, thereby the need for an additional system call arises. Thus, the usage of MSG_MORE seems more appropriate to me. I'd simply change the above send() line to: int sent = send(this->fd, buf, len, MSG_NOSIGNAL | MSG_MORE); According to lwm.net, packets will be flushed automatically if they are large enough: If an application sets that option on a socket, the kernel will not send out short packets. Instead, it will wait until enough data has shown up to fill a maximum-size packet, then send it. When TCP_CORK is turned off, any remaining data will go out on the wire. But this section only refers to TCP_CORK. Now, what is the proper way to flush MSG_MORE packets? I can only think of two possibilities: Call send() with an empty buffer and without MSG_MORE being set Re-apply the TCP_CORK option as described on this page Unfortunately the whole topic is very poorly documented and I couldn't find much on the Internet. I am also wondering how to check that everything works as expected? Obviously running the server through strace' is not an option. So the only simplest way would be to usenetcat' and then look at its `strace' output? Or will the kernel handle traffic differently transmitted over a loopback interface?

    Read the article

  • [C#] Async threaded tcp server

    - by mark_dj
    I want to create a high performance server in C# which could take about ~10k clients. Now i started writing a TcpServer with C# and for each client-connection i open a new thread. I also use one thread to accept the connections. So far so good, works fine. The server has to deserialize AMF incoming objects do some logic ( like saving the position of a player ) and send some object back ( serializing objects ). I am not worried about the serializing/deserializing part atm. My main concern is that I will have a lot of threads with 10k clients and i've read somewhere that an OS can only hold like a few hunderd threads. Are there any sources/articles available on writing a decent async threaded server ? Are there other possibilties or will 10k threads work fine ? I've looked on google, but i couldn't find much info about design patterns or ways which explain it clearly

    Read the article

  • TCP/UDP and ethernet MTU Fragmentation

    - by Fantastic Fourier
    I've read various sites and tutorials online but I am still confused. If the message is bigger than IP MTU, then send() returns the byte sent. What happens to the rest of the message? Am I to call send() again and attempt to send rest of the message? Or is that something IP layer should take care of automatically?

    Read the article

  • In TCP/IP terms, how does a download speed limiter in an office work?

    - by TessellatingHeckler
    Assume an office of people, they want to limit HTTP downloads to a max of 40% bandwidth of their internet connection speed so that it doesn't block other traffic. We say "it's not supported in your firewall", and they say the inevitable line "we used to be able to do it with our Netgear/DLink/DrayTek". Thinking about it, a download is like this: HTTP GET request Server sends file data as TCP packets Client acknowledges receipt of TCP packets Repeat until download finished. The speed is determined by how fast the server sends data to you, and how fast you acknowledge it. So, to limit download speed, you have two choices: 1) Instruct the server to send data to you more slowly - and I don't think there's any protocol feature to request that in TCP or HTTP. 2) Acknowledge packets more slowly by limiting your upload speed, and also ruin your upload speed. How do devices do this limiting? Is there a standard way?

    Read the article

  • Is it possible to add tcp autotuning to windows xp?

    - by Caspin
    I have a network application that needs to send messages at 60 times a second. The messages are usually 300-400 bytes, but can be as large as 1500. The default setting for SO_SNDBUF is too small and limits the number of message that can be sent if the network latency is anything greater then 100ms. The naive solution is to just bump the SO_SNDBUF size to to something large. However, depending on the latency and the packet size that could be anywhere from 64K to 8MB. One of Vista's new features is TCP autotuning. Autotuning monitors the tcp connection and dynamically adjust the buffer sizes to allow for optimal communication. I would like to use auto tuning on our windows xp machine so I don't need to guess what my buffers sizes should be. Is there a way to install either a microsoft or 3rd party tcp autotuner on windows xp?

    Read the article

  • Is it possible to add tcp autotuning to windows xp?

    - by Caspin
    I have a network application that needs to send messages at 60 times a second. The messages are usually 300-400 bytes, but can be as large as 1500. The default setting for SO_SNDBUF is too small and limits the number of message that can be sent if the network latency is anything greater then 100ms. The naive solution is to just bump the SO_SNDBUF size to to something large. However, depending on the latency and the packet size that could be anywhere from 64K to 8MB. One of Vista's new features is TCP autotuning. Autotuning monitors the tcp connection and dynamically adjust the buffer sizes to allow for optimal communication. I would like to use auto tuning on our windows xp machine so I don't need to guess what my buffers sizes should be. Is there a way to install either a microsoft or 3rd party tcp autotuner on windows xp?

    Read the article

  • TCP 3 way handshake

    - by Tom
    Hi, i'm just observing what NMAP is doing for the 3 ports it reports are open. I understand what a half-scan attack is, but what's happening doesnt make sense. NMAP is reporting ports 139 are 445 are open..... all fine. But when i look at the control bits, NMAP never sends RST once it has found out the port is open, It does this for port 135- but not 139 and 445. This is what happens: (I HAVE OMITTED THE victim's replies) Sends a 2 (SYN) Sends a 16 (ACK) Sends a 24 (ACK + PST) Sends a 16 (ACK) Sends a 17 (ACK + FIN) I dont get why NMAP doesnt 'RST' ports 139 and 445??

    Read the article

  • C# TCP First Message Delay

    - by ikurtz
    greetings, i am writng a socket program using sockets in c# (asynchronous). the issue is, when a client connects to the server it kinda happens quiet fast. then.. when the first message is sent there is a delay in responding. this only happens to the very first data being sent over the connection. and boh client and server suffers from this behaviour. what is this delay? is there a way to get rid of this? many thanks.

    Read the article

  • OpenVPN Clients using server's connection (with no default gateway)

    - by Branden Martin
    I wanted an OpenVPN server so that I could create a private VPN network for staff to connect to the server. However, not as planned, when clients connect to the VPN, it's using the VPN's internet connection (ex: when going to whatsmyip.com, it's that of the server and not the clients home connection). server.conf local <serverip> port 1194 proto udp dev tun ca ca.crt cert x.crt key x.key dh dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log verb 9 client.conf client dev tun proto udp remote <srever> 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert x.crt key x.key ns-cert-type server comp-lzo verb 3 Server's route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 69.64.48.0 * 255.255.252.0 U 0 0 0 eth0 default static-ip-69-64 0.0.0.0 UG 0 0 0 eth0 default static-ip-69-64 0.0.0.0 UG 0 0 0 eth0 default static-ip-69-64 0.0.0.0 UG 0 0 0 eth0 Server's IP Tables Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-proftpd tcp -- anywhere anywhere multiport dports ftp,ftp-data,ftps,ftps-data fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:20000 ACCEPT tcp -- anywhere anywhere tcp dpt:webmin ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:imaps ACCEPT tcp -- anywhere anywhere tcp dpt:imap2 ACCEPT tcp -- anywhere anywhere tcp dpt:pop3s ACCEPT tcp -- anywhere anywhere tcp dpt:pop3 ACCEPT tcp -- anywhere anywhere tcp dpt:ftp-data ACCEPT tcp -- anywhere anywhere tcp dpt:ftp ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- 10.8.0.0/24 anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-proftpd (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- anywhere anywhere My goal is that clients can only talk to the server and other clients that are connected. Hope I made sense. Thanks for the help!

    Read the article

  • How do I optimize TCP stack for HTTP server?

    - by jcisio
    I have a HTTP server that serves only two kinds of page: about 10 KB and about 16 KB (both compressed, other files are from CDN). As the latency is quite high (ping takes more than 300 ms), I want to optimize the TCP stack so that client receives the whole page ASAP. Thus, I have a double question: Which parameter do I have to change (which value of TCP window)? How to change in (a Debian box, and FYI, there is a Varnish before the HTTP server).

    Read the article

  • iptables & allowed port refusing connection

    - by marfarma
    Can you see what I'm doing wrong? On Ubuntu Server 9.1, I'm attempting to allow traffic on port 1143 for a non-privileged IMAP host. Connection is refused when testing with telnet example.com 1143 but connection is allowed testing with telnet example.com 80 from my pc to remote internet hosted server. Both rules appear identical and are located near each other with no rules rejecting connections intervening in the rules file. I can't figure it out. iptables -L returns this: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt ACCEPT tcp -- anywhere anywhere tcp dpt:7070 ACCEPT tcp -- anywhere anywhere tcp dpt:1143 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT icmp -- anywhere anywhere icmp echo-request LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: ' REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere and my rules file contains this: # Generated by iptables-save v1.4.4 on Wed May 26 19:08:34 2010 *nat :PREROUTING ACCEPT [3556:217296] :POSTROUTING ACCEPT [6909:414847] :OUTPUT ACCEPT [6909:414847] -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080 -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080 COMMIT # Completed on Wed May 26 19:08:34 2010 # Generated by iptables-save v1.4.4 on Wed May 26 19:08:34 2010 *filter :INPUT ACCEPT [1:52] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1:212] -A INPUT -i lo -j ACCEPT -A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT -A INPUT -p tcp -m tcp --dport 7070 -j ACCEPT -A INPUT -p tcp -m tcp --dport 1143 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 -A INPUT -j REJECT --reject-with icmp-port-unreachable -A FORWARD -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -j ACCEPT COMMIT # Completed on Wed May 26 19:08:34 2010

    Read the article

  • Can I use TCP as DNS query protocol on Mac OS?

    - by Brian
    Hi, I'm using Mac OS, Snow Leopard 10.6.2, and I'm suffering from UDP packet loss during DNS query. So I tried DNS query as TCP using dig command, it worked very well. However, I can't find some control switch to change to use TCP during DNS query. Is there a way to change it in Mac OS? Thank you.

    Read the article

  • Can I use TCP as DNS query protocol on Mac OS?

    - by Brian
    Hi, I'm using Mac OS, Snow Leopard 10.6.2, and I'm suffering from UDP packet loss during DNS query. So my web browser is too slow to surf internet nicely. But it worked very well when I tried a DNS query on TCP using dig command. However, I can't find some control switch to change to use TCP during DNS query. Is there a way to change it in Mac OS? Thank you.

    Read the article

  • is it possible for a host to maintain a tcp connection with two hosts with the same IP?

    - by wenzi
    I have two hosts A and B and a host(called client here) C C will establish a tcp connection with A, and send http requests to A then A will relay the HTTP requests to B (the relaying may be seconds of delay) and B will spoof its IP address as the IP of A and send http response to C I know there is sequnce number inconsistency problem, but is it possible to trick the TCP protocol to make the connection viable? thanks!

    Read the article

  • is it possible to synchronize the states of TCP proxies in real time (for real-high-availability of SLB)?

    - by Song
    Consider that there are two server load balancers working in the tcp proxy mode (e.g., for L7 load balancing). Is it possible to synchronize their states in real time so that they can be a backup for each other? in case that one is down, the other still has all necessary states to uninterruptedly support all existing TCP connections. I understand that this is hard, but I am wondering whether any free/commercial LB already supports this feature. Thank you!

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 6 7 8 9 10 11 12 13 14 15 16 17  | Next Page >