Comments and Discussions

I noticed a little fault in STUN_Client.cs. In method DoTransaction a wait time of 100 is specified for the Poll method. However the wait time of the socket.Poll method is in microseconds, not in milliseconds. Therefore a retransmission is done every 100 microseconds rather than every 100 milliseconds as the comment suggests.

I also read that for the new STUN protocol the retransmission timeout should start at a value of 500 milliseconds, so I assume that 100 milliseconds is quite short actually.

Thanks for writing a very good article on Stun client.I get the public ip and port using your code, but i don't understand yet how to connect with other machine. can i use the returned socket from stun to coonect with other machine or i have to do something else ?

STUN only helps you to determine your own public IP and UDP port. To connect clients directly via UDP you need 'UDP hole punching'. The best article I found on this is here: http://www.brynosaurus.com/pub/net/p2pnat/

No matter what, you'll additionally need a rendezvous server, which assists in establishing a direct connection between to UPD clients. However, the public STUN servers are still very helpful. In my case I have a hosted website, where I can deploy HTTP web services. However, I cannot connect to the web server via UDP. So the solution is that clients use a public STUN server to determine their public IP and UDP port, then use an HTTP-based web service to transmit rendezvous information (public IP and port), and finally connect to each other directly via UDP again using the UDP hole punching technique.

My problems is that when i've got a global & local mapped address and the next step is to open a communication channel, but i don't know how to do it! Could you please give me a simple example of message transfer between node through STUN?

Check out my answer under 'How i connect to remote machine using Stun'. You'll have to figure out how to use UDP under WCF and use the hole punching technique to make it work. STUN only helps you to find out the necessary info, public IP and port, to do hole punching. You'll also need an additional rendezvous server.

I tried testing with JSTUN client, it gives the expected result in terms of response FullCone, RestrictedCone.. But it does not give the IP address and the mapped port. May be there is problem with the flow of the algorithm implemented in your client?

Hi,would this project work fine if I try to recompile for compact framework ?if not what modifications do I need. I understand that the forms are not the same since WM5 is based on WinCE but would the client work fine?

The NAT server only let us know about our server-side ip and port. But when each peer know its server-side ip and port, they need to send that information to each other, right ? And they cannot send directly to each other, so do u know any server do that (we can connect to that server, send our information, and server send that information to the other peer...) ?

I have STUN server and running the stun client demo program from outside the firewall. I get the NAT type as UdpBlocked but I have Wireshark running on the firewall machine and it shows UDP is transmitted. What do you think the problem? Thanks for the excellent program

I want to make a file transfer program using STUN to pass through NAT, but I think UDP protocol isn't suitable for this, right ? And I can't find any STUN for TCP. So do you have any suggestion for me ? Do I have to build a protcol like TCP based on UDP ???

You must use UDP. The only way it packetize file in to UDP chunks and add checksum for each chunk. SO you only need to make some logixc what keeps track what chucks not reaced ant retransmit them. md5 chek sum quarrantees that chunk data not corrupt.

>Can it also support for sending/receiving video packet ?Seems you have get wrong idea about stun. stun is just for discovering pubic ip and port of NAT behind IP endpoint.Most common video transport is RTP.

>How long that stunserver will be site situation on the net ?I think if you reread your question, then even you dont get what you mean by this.

>Can it also support for sending/receiving video packet ?Seems you have get wrong idea about stun. stun is just for discovering pubic ip and port of NAT behind IP endpoint.Most common video transport is RTP.

OK,i see,but let me ask you that if port of NAT is discovered and mapped by stun,can i use it to transport video stream over the internet ?If i'm wrong understanding,please suggest.

Theoretically you can when both computers start sending data each other. Otherwise NAT won't pe opened !!!Normally some kind of signalling protocol is used to setup session. For example voip phones use SIP + SDP for that.

NAT is opened(only for remote target) after you send out initial request to target.And from there: if both endpoints behind NAT, both must send data to each other to make actual data flow.(computerA - NAT - INTERNET - NAT - computerB)

Let me know again,if stun client run on both that mean they're the remote target where NAT is also opened by stun for each remote (that's incoming host)after that if they need to communicate both must send data ie. external ip and port to each other then they can make actual data flow on the network.Is i right understanding ?

Nice work, but you made a little mistake regarding the retransmit time.

9.3 Formulating the Binding Request

Clients SHOULD retransmit the request starting with an interval of 100ms, doubling every retransmit until the interval reaches 1.6s. Retransmissions continue with intervals of 1.6s until a response is received, or a total of 9 requests have been sent. If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed. In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms

Thats not typo, thats simplified solution.Normally retransit wont happend in reallife, so if you retransmit 200mx,200ms , ... i dont see any problem about that.But though it's not 100% RFC comilant ... .

Your approach is almost RFC comiplant, but if to splitting hair- -- except: If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed.