Greetings, all. I've been fiddling with Winsock 2.2 programming with some success. I've written an app that uses TCP, and it functions rather well. Recently, however, I've attempted some UDP programming. In order to get an idea what kinds of troubles I'll have to deal with over the internet, I wrote a small chat program that also sends packets to the other machine to perform an analysis on packet loss and overall data rate. It entirely uses UDP, which of course, presents its own difficulties... The one I want to ask about here is the concept of "solicited UDP". Apparently, some routers that otherwise block UDP packets will recognize an outgoing UDP packet and will temporarily allow a response through the sending packet's port. This allows the host side to send a response back and allow the sending machine to receive it. However, in my initial testing, the client's machine was failing to receive my packets at all (I was serving as the host). The client connects by first sending a UDP packet with username information. Then, when the client types in a chat message, that request is sent to the host which then sends the chat message back to the client to be echoed on their screen. The client wasn't seeing those messages, so this apparently wasn't working. I've tested it on my LAN, and my local machine, and it works fine. * My primary question is: Is there a way in Winsock to flag a sent UDP packet as "solicited", or is this entirely an automatic router function? Any links to articles or mention of Winsock functions and flags to set would be appreciated. I've been combing through MSDN and various other google attempts to no avail. Thanks for any insight! [Edited by - Waverider on September 28, 2008 9:33:32 PM]

Quote:Original post by Evil Steve
The problem is that you need to be able to get through on one side before you can send a reply.

Thanks for the link, I'll take a look at it.

In response to this comment, I didn't make it clear that I did in fact see login information and chat messages from the client, he just wasn't getting them back from me. Will NAT punch-through still help?

UDP is connectionless, so I'm just replying using a reserved socket (not one directly generated from the client connecting as TCP would, just one I allocated space for) and the address info sent on the login request. It works locally and on my LAN, so I was assuming it would work on the internet as well.

However, I could see where a router with its DMZ set to a different machine would route the packet incorrectly. Routers might do some things automatically, but I don't expect they would be able to predict where a UDP packet is REALLY meant to go...

Frustrating.

Maybe I should just try the app with someone else. Perhaps that first user's setup is just being difficult.

After our little troubles, he opened up the port it hosts on and we reversed roles. I DMZ'd my machine so that I would be sure to receive the responses. That part worked fine.

By the way, UDP packets above 1k size fragment often enough to not bother with... :P

I just tried it again with my router NOT DMZ'd with him hosting, and it worked. So something about his setup prevents my host from sending a packet to him, but my router allows solicited UDP just fine.

How is he browsing? (DNS requests are UDP, that's how I found out about "solicited" in the first place).

Oh well, at least I learned something!

Thanks!

I just tried hosting with someone else... same problem.

Curses.