Ambigram Generator

It's cool! Thanks to Tanim for sharing this.

Go to http://www.flipscript.com/ and hit "Create New Ambigram".

TURN turns RFC too

Traversal Using Relays around NAT (TURN) from the IETF working group "Behave" became RFC 5766.

ICE becomes RFC 5245

Interactive Connectivity Establishment (ICE) is a protocol for Network Address Translator (NAT) traversal for offer/answer protocols. The Internet Engineering Task Force (IETF) recently approved it as RFC 5245.

Reusing TCP Connections: "address already in use"

The socket option SO_REUSEADDR is useful for binding a socket to a port that is already in use by another socket. But even if you are successful in binding the socket, it does not mean you will not get the "address already in use" error later with that socket.

Consider a case where you want to connect from a fixed source port (srcport) and IP (srcip) to a fixed destination port (dstport) and IP (dstip) using TCP. A TCP connection is basically a 5-tuple (srcip, srcport, dstip, dstport, protocol).
The first attempt with connect() succeeds and the connection is established.
But, depending on your OS configuration, you may not be able to establish the same connection again for a while, even if you close the first connection. Even though you may succeed with SO_REUSEADDR binding the (srcip, srcport, TCP) 3-tuple, your connect() call will fail to establish the 5-tuple.

This is a very unlikely use-case because usually, clients do not need to use the same srcport in a subsequent connection. But I encountered this problem when I was developing an ICE-TCP library for a client who wanted to specify a fixed port to be used in the SDP generated by the library. In this case, there is a chance that the same fixed port will be specified for a call after the previous call ends.

This problem arises from the TIME_WAIT state of TCP.

To get around this problem, you need to "hard close" the first connection (as opposed to "graceful shutdown"). For this, set the option SO_LINGER to the socket of the first connection, with a linger timeout of zero. Then when you want to close the connection, DO NOT call shutdown(). Call only closesocket(). If you call shutdown(), a graceful shutdown is initiated with the [FIN, ACK, FIN, ACK] sequence, which ultimately leads to the stuck TIME_WAIT state.

So, in summary, if you desparately need to reuse a TCP connection 5-tuple and want to avoid the "address already in use" problem, use SO_REUSEADDR, SO_LINGER and closesocket(), and avoid shutdown().

To know more about the TIME_WAIT state and other details, check out the following links:
http://www.developerweb.net/forum/showthread.php?t=2941
http://hea-www.harvard.edu/~fine/Tech/addrinuse.html

Reusing Ports: Socket Option SO_REUSEADDR

Recently, I came across a situation where I had to bind the same port to multiple sockets. I am just going to write some brief notes about this.

Is it possible to bind multiple sockets to the same port?
Yes, it is possible.

How?
There is a socket option for this, called SO_REUSEADDR.

Why would someone want to reuse a port?
This option is sometimes needed. For example,

1. Suppose you have restriction on the number of ports you can use. Then you may want to use the same port for connecting to different destinations.
2. The original use case for this option occurs when a socket is closed. It may "linger" for a while, because there is still unsent data in the buffer. So you cannot use (bind to) that port right away after the socket is closed. So you can set SO_REUSEADDR on that socket, if you think the port needs to be usable right away after closing a previously bound socket.

Can I prevent a port from being reused or hijacked?
Yes, you can.
In Linux, if you do not set SO_REUSEADDR on a socket, the port bound to that socket cannot be rebound by another socket.
But in Windows, even if you do not set SO_REUSEADDR, that port can be bound to another socket if the second socket sets SO_REUSEADDR before bind!
In order to prevent this, Windows provides another option called SO_EXCLUSIVEADDRUSE. When this option is set on a socket, the port bound to that socket cannot be reused by another socket.

Example problem
I would like to bind any free port to socket S1. Then I would like to bind that specific port to socket S2 as well.

Solution

1. Bind any free port to S1 (specifying zero for port does this).
2. Set socket option SO_REUSEADDR to S1 (Do not set this before binding, so that an unused port is guaranteed to be bound to S1 in step 1).
3. Find out the port number P that is bound to S1 (getsockname can be used for this).
4. Set socket option SO_REUSEADDR to S2 (Some OS may not need this step. But it does not do any harm to do it anyway).
5. Bind the specific port P to socket S2.

NAT traversal - MS-ICE2 and MS-TURN

For the last few months, I have been working on changing Eyeball AnyFirewall Engine (AFE) so that it can work with Microsoft Office Communication Server (OCS) and Microsoft Office Communicator 2007 R2 (MOC).

OCS is basically a SIP server. One part of OCS is called the "edge" server, which acts as a TURN server.

MOC is a SIP client. It can make voice or video calls.

AFE is a NAT traversal library that offers a high-level API to be used by an application. AFE uses IETF standards STUN, TURN and ICE to solve the NAT traversal problem in VoIP.

TURN is the protocol which can be used by a client to open a "relay port" in a TURN server. If the client is unable to use a host port for being behind a NAT, it can use the relay port or the server-reflexive port for its purpose. The TURN server is normally located outside any NAT.

ICE is a protocol by which two clients can weigh the possibility of establishing connection between them through different paths, and choose the optimal one. This is done by exchanging STUN connectivity checks.

MOC and OCS use protocols that are slightly different from the IETF standards. For example, MOC uses MS-ICE2 based on IETF ICE-19. For communicating with the OCS edge server, MOC uses MS-TURN, which is based on IETF midcom TURN-08.

There are many details about the implementation of these protocols. Allocating the relay ports, forming the SDP, carrying out ICE connectivity checks, nominating the best path - these are some of the broad steps.

The AFE can now successfully interop with MOC and OCS. Initially, we had a tough time figuring out why some of the ICE checks were failing randomly. Later it was found that the CRC table used by MOC for the calculation of STUN fingerprints is slightly different from the usual table in one value. After adapting this, everything is running quite smoothly.