NUTSS STUNT Publications Project Page Downloads
IMPORTANT NOTICE: Code for this project is no longer maintained, and is released to the public domain. The NAT testing and classification server, however, will continue to operate. The concepts behind this work are being rolled in ICE-TCP, which we expect will find it's way into various open-source libraries such as PJNatH and libJingle. Feel free to contact Saikat if you have general questions about TCP NAT traversal.

libnutss

  • Binaries: download
  • Source: srpm bz2 zip
  • Examples: nutssping other examples
  • Docs: API reference

NAT Testing Software

  • Client: Windows, Linux
  • Server: Linux
  • Running the Client
  • Client Documentation
  • Server Documentation
  • Frequently Asked Questions
  • Survey Results
  1. What does the stunt.jar library provide?
  2. Can applications use non-blocking IO with the STUNT library?
  3. Can STUNT be used as a complete replacement for old Socket based code?
  4. Why do socket functions use URI's for specifying the remote end-point and not IP address and ports?
  5. How does one write a server-client or peer-to-peer applications with the library?
  6. Does the library require some infrastructure?
  7. Does the library require special privileges?
  8. Does the rendezvous server proxy data?
  9. Who provides the rendezvous and STUNT service? Who can use them?
  10. Is this library under active development? Will you implement feature X?
  11. I want to implement TCP NAT traversal in my application but don't want to use your library?
  1. What does the stunt.jar library provide? It provides a way to establish unproxied TCP connections between two end-points, both of which can be behind a NAT. It returns a SocketChannel that can be used for blocking or non-blocking IO as the application desires.
  2. Can applications use non-blocking IO with the STUNT library? Yes. The application registers callbacks when it initiates a socket. When a connection is accepted by a server end-point, or when a client end-point succeeds in connecting, or when an error occurs during the connection initiation, the callback functions are called asyncronously.
  3. Can STUNT be used as a complete replacement for old Socket based code? Yes and No. STUNT connectivity between peers is strict better than plain sockets' connectivity i.e. if you could connect using sockets before STUNT, you'll still be able to connect with STUNT and, in addition, you'll be able to connect to other end-points to which you could not previously connect. However, the STUNT library has not been optimized for connection-establishment-latency. Therefore, it make take little longer to connect to end-point using STUNT that you could already connect to with plain sockets. As a result, the recommended way of using the STUNT library is to try the plain-socket connection first and if that fails, then fall back to the STUNT library. Another option would be to modify the library and optimize for connection-establishment-latency for your particular set of users.
  4. Why do socket functions use URI's for specifying the remote end-point and not IP address and ports? IP addresses and ports are not unique when NATs are present. In order to uniquely identify the remote end-point, STUNT uses URIs which look like email addresses.
  5. How does one write a server-client or peer-to-peer applications with the library? We have provided a simple server-client application consisting of an EchoServer that accepts inbound connections from one or more EchoClient applications.
  6. Does the library require some infrastructure? Yes. The library requires a rendezvous server (much like a directory server) where applications with one URI can find the application with another URI and coordinate to establish a connection. The library also requires some STUNT servers that help applications find out their external IP address and port for establishing the real connection.
  7. Does the library require special privileges? No. The library can function equally well with user privileges on both Windows and Linux. You do not need administrator or super-user privileges to run the library.
  8. Does the rendezvous server proxy data? No. The rendezvous server only helps set up the connection. After that, all data is exchanged directly between the end-points and does not go through the rendezvous server.
  9. Who provides the rendezvous and STUNT service? Who can use them? We at Cornell University are providing a rendezvous and STUNT service for developers and researchers to use. However, if you wish to deploy your own application that uses the library, we ask that you set up rendezvous and STUNT servers only for your own applications such that you do not overburden the Cornell service (which is for research and development purposes) and so that outages and changes in the Cornell service doesn't affect your application. The rendezvous server and STUNT server code is freely available.
  10. Is this library under active development? Will you implement feature X? The library is a proof of concept that TCP NAT Traversal is possible and is intended to be a starting-poing for application developers who want to use it in a real-world deployable project. At the same time, it is a library that can be used more-or-less unmodified for research and quicky-development and prototyping of applications. Time permitting, I would like to implement various features that are requested; but I cannot promise that all features will be implemented in a timely fashion. I will do my best to make the library more suited to its primary goal -- show how the NAT TCP problem can be solved easily by applications.
  11. I want to implement TCP NAT traversal in my application but don't want to use your library? The TCP NAT traversal code is contained in the file STUNTCont.java. It includes extensive documentation. Feel free to adapt the code to your application. The rendezvous service and the STUNT service are modular and may be replaced by your own implementations if you wish to use the rest of the library.