Home
Fractals
Tutorials
Books
My blog
My LinkedIn Profile

BOOKS i'm reading

Napoleon Hill Keys to Success: The 17 Principles of Personal Achievement, Napoleon Hill, ISBN: 978-0452272811
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich (Expanded and Updated), Timothy Ferriss, ISBN: 978-0307465351
The Fountainhead, Ayn Rand, ISBN: 0452273331
Web Hosting Canada

mailto:olivier@olivierlanglois.net

Category: TCP/IP

06/05/08

Permalink 11:08:40 pm, by lano1106, 669 words, 27187 views   English (CA)
Categories: TCP/IP

CLOSE_WAIT vs TIME_WAIT

While we were using an Apache ActiveMQ broker at my job. It has been reported by the operators last week that the broker could not open new sockets because it has reached the maximum limit of open file descriptors. The operators have also mentioned that the majority of the TCP sockets where in the CLOSE_WAIT state. My initial reaction has been to confuse the TCP state CLOSE_WAIT with the TIME_WAIT state.

Yesterday, someone else reported the same problem on the Apache ActiveMQ developers’ mailing list and I have noted by reading posts from people trying to suggest workarounds that I was not the only one to mix up the TCP state CLOSE_WAIT and TIME_WAIT. So this gave me the idea to take this opportunity to write about the differences between these 2 states since apparently there is a widespread need for clarifications on that matter.

A TCP connection goes into the CLOSE_WAIT state when it receives a FIN segment from its peer. From that point the connection becomes half-duplex and the TCP connection will not receive any new data from its peer but it will still be able to send any amount of data back to the peer. Hence, the socket will stay there as long as the server does not call close() explicitly on the socket.

I am not sure on this but I think this is exactly what the state name means. The socket is waiting for the application to call close() before going away.

TIME_WAIT is the TCP state a connection will go when it performs an active close (it is initiating the connection shutdown) after having received the peer FIN segment and sent it back an acknowledgment for the FIN.

The connection will stay in that state for 2 times the maximum segment live (MSL). As an interesting side note, the MSL has nothing to do with IP time to live (TTL) or the TCP connection round time trip (RTT). The MSL value is a constant and varies from one TCP implementation to another. RFC 793 suggests using 2 minutes for the MSL and the implementation shown in this book is using 2 minutes but 4.4BSD is using 75 seconds and Linux close to 4 minutes. The reason why MSL is unrelated to IP TTL and RTT is that a TCP segment can outlive the IP packet carrying it even if routers takes longer than usual to deliver it since a TCP stack will retransmit it.

TIME_WAIT is needed because it is possible that the TCP acknowledgment for the received FIN gets lost (or any segment containing data prior the FIN). In that case, the peer will try to retransmit its FIN for the MSL period. Waiting for a longer period than MSL is the only choice TCP can make as there are no acknowledgements for ACKs (that would be recursive anyway and solve nothing if ACKs were acknowledged).

I have been wondering for some time why TCP does not wait 2 times MSL before leaving the LAST_ACK state like it does for TIME_WAIT since there are scenarios where TCP could receive packets from the previous connection after leaving LAST_ACK and I think that I have understand why. In TIME_WAIT, you want to handle peer retransmission otherwise it could think that its last segments have never been received. In LAST_ACK, there is nothing else to acknowledge so it does not matter if TCP reset the connection after leaving LAST_ACK.

For instance, let’s say that the stack retransmits its FIN and both the original FIN and the retransmitted one get acknowledged. What will happen is that at the reception of the first ACK, TCP will release its Transmission Control Block (TCB) associated to this connection and at the reception of the second ACK, it will reply with a RST. It is no big deal. The other peer will be in the TIME_WAIT state and will just conclude that the peer is gone when it will read the RST.

05/23/07

Permalink 06:11:22 pm, by lano1106, 699 words, 16508 views   English (CA)
Categories: TCP/IP, Video games

NAT traversal for the dummies and the best NAT router for online gaming

A NAT router is a device that allow many computers to share the same IP address. You can learn more about NAT itself from Internetworking with TCP/IP, Vol 1 (5th Edition). One drawback of using NAT is that to communicate with someone outside the private network, you must initiate the communication from the private network. This is all fine for contacting a web server but this is making peer to peer applications such as file sharing or gaming harder. There are some techniques to perform NAT traversal but what makes the matter worse is that NAT routers have a different NAT behavior from a model to the other and as if it was not bad enough, these behaviors are totally undocumented. Things are about to change as the RFC 4787 describes a set of behaviors that a router should have to be gaming friendly. So my advice as a person who has worked at Quazal, a big well known multiplayer online middleware company, if you want the best NAT router for online gaming for your video game console (Xbox, Xbox360, Nintendo Wii, Playstation 2, Playstation 3 or PSP), you should look for a router that is RFC 4787 compliant. They might be hard to find now as the RFC has been released just few months ago but if I personnally was looking to purchase a new router, that is what I would be looking for.

The basic principle to perform NAT traversal is that you need a server on the public network that will be used as a traversal probe relay. Lets say that client A and client B that are located behind 2 distinct NAT routers. They first have to contact the server. The server must keep the address from which it receive data from the clients. These addresses are the public address of the clients behind the NAT router as seen from the server. When client A wants to establish a connection with client B, it will first request the client B public address from the server and start sending probes to B public address. At the same time, client A will send a request to B by using the server as a relay to start sending probes to itself. What will happen is since both clients try to establish a connection with each other at the same time, there should be a midair collision where a hole has been created for the other on each of their respective router. This technique is called hole punching and there is an RFC describing a protocol that implement this principle. The protocol name is STUN (Simple Traversal of UDP for NAT).

NAT traversal for TCP is much harder because TCP handshaking for establishing a connection is asymmetric. To workaround that problem, you have to trick the TCP protocol and the router that might monitor the TCP handshake. There is not yet an official protocol but some proposals exist. One of them is STUNT (STUN for TCP) but the name is funny because it has also a second meaning. The way STUNT works is that both side will initiate a connection by sending a SYN packet with a short TTL (Time To Live). The TTL value must be carefully choosen so the packet goes out of the private network but does not reach the destination. Then the stack itself or a packet sniffer must read the sequence number contained in the SYN message and send the read value to the STUNT server. The server will then impersonate the other endpoint and spoof the SYN/ACK reply. Then the last step of the connection which is to send the final ACK can be sent as usual and if everything has worked fine, the TCP connection will be established normally. I will stop the NAT traversal explanation here as there are a lot of good resources on the net. Here are the most interesting:

Update (12/05/2010): I have written a review of Linksys and a Netgear gaming router if it can help you to choose the right router for your needs.

05/22/07

Permalink 10:21:07 pm, by lano1106, 335 words, 1721 views   English (CA)
Categories: TCP/IP

SMTP client configuration

While setting up my Microsoft Outlook 2003 client to use my new hosting company, BlueHost, SMTP server, I was always getting a connection timeout every time I was clicking on the 'Test account settings'.

After investigating further the problem, I have found out that a TCP connection was established with the server but it was taking an unusual long time (around 35 seconds) before receiving the server '220' "Greeting" reply.

My first reflex has been to look into my book Internetworking with TCP/IP, Vol 1 (5th Edition) in the chapter on Electronic Mail and I have found:

If the server is overloaded, it may delay sending the 220 READY FOR MAIL message temporarily.

Then I went to check what the RFC 2821 text was saying about that topic and I have found in section 4.5.3.2 Timeouts:

Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:

Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.

Here you go. The RFC recommends to set the timeout value to 5 minutes and the Microsoft Outlook 2003 default value found in the 'Advanced' tab of the 'More settings' dialog is one minute. I have tried to set it to 5 minutes and then I have retried to test my new settings again. The test was still failing. I have found out the reason. The server timeout seems to be hardcoded to 30 seconds or less when you click on the 'Test Account Settings...' button.

So, to make a long story short: If you have to connect to an overloaded SMTP server with Microsoft Outlook 2003 client (I do not know if there are other versions affected with this bug), the real test for your new account settings is not the test button but to actually try send manually a test e-mail.

<< Previous Page ::

Olivier Langlois's blog

I want you to find in this blog informations about C++ programming that I had a hard time to find in the first place on the web.

< Previous |

March 2024
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Search

Custom Search

Misc

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 5

powered by
b2evolution