Impossible, even for you??

[rickyk586]

Is there any way to establish a TCP connection between two client sockets without one of them being a server?

Task: To establish a connection between two computers.

Requirements:

* TCP connection (socket)
* The two computers to be connected cannot listen to ports/accept connections (like a server does).
* The two computers can however initiate a TCP connection (like a client does)
* The network path between the two computers cannot be listened to (sniffed).
* Any number of computers can be used, and these restrictions only apply to the two computers to be connected.


I am 99% sure that this task is impossible, but there are some pretty smart people out there so I may be wrong...

[Richard.J]

- any number of computers possible, so 1 computer is OK
- the loopback interface (127.0.0.1) can not be sniffed
- both clients may connect to a server which simply passes the messages received from one client to the other.

HTH, and greetings to your teacher,
Richard

[Lindley]

Oddly enough, I'm pretty sure the TCP spec contains provisions for both sides trying to connect to each other at the same time. However, the Berkley sockets interface doesn't allow that.

[MikeAThon]

Search for "TCP hole punching". The original is by Bryan Ford at http://www.bford.info/pub/net/p2pnat/

Both computers make a close-to-simultaneous outbound connection to a common rendezvous server, which is then sends information to the two computers that allows them to connect to each other.

Mike

PS: My regards to your teacher too.

[rickyk586]

- any number of computers possible, so 1 computer is OK
- the loopback interface (127.0.0.1) can not be sniffed
- both clients may connect to a server which simply passes the messages received from one client to the other.

HTH, and greetings to your teacher,
Richard
Not bad, thinking outside the box, but the question clearly states that there are 2 computers to be connected.

Search for "TCP hole punching". The original is by Bryan Ford at http://www.bford.info/pub/net/p2pnat/

Both computers make a close-to-simultaneous outbound connection to a common rendezvous server, which is then sends information to the two computers that allows them to connect to each other.

Mike

PS: My regards to your teacher too.
This is as close as I got too. But read the second bullet under the section '4.3 Behavior Observed by the Application'. It says that in this case (which it also says is what Windows does) you need to listen to ports to accept a connection: "TCP creates a new stream socket with which to associate the new TCP session, and hands this new socket to the application via the application's next accept() call on its listen socket.". So, I guess it would work with BSD-based OS's not needing to listen to ports, but TCP hole punching will not work with Windows. The problem arises with the Sequence Numbers in the SYN and SYN-ACK packets.

[rickyk586]

Any other ideas??