   "Solicited UDP packets"? [RESOLVED 9/28]
  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 WaveriderHowever, in my initial testing, the client's machine was failing to receive my packets at all (I was serving as the host).* 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!There's no flag to do this, no. It's entirely up to the router. If there was such a way, then everyone would just flag them as such to get through routers.The problem is that you need to be able to get through on one side before you can send a reply. Have a look on google for NAT Punch Through, this link looks promising.   ;Quote:Original post by Evil SteveThe 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?;Quote:Original post by WaveriderIn 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?Ah I see, sorry. I don't think NAT punch-through will be much use here, that's more for when both sides are behind a router.Are you using the same SOCKET to send and recieve on? I'm a bit rusty on UDP unfortunately [smile]   ;  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.   ;Quote:Original post by WaveriderMaybe I should just try the app with someone else.  Perhaps that first user's setup is just being difficult.It's definitely worth a shot. You could try forwarding the UDP port you're using on the router to check that works - if it doesn't, then there's a chance the packet is being dropped on the Internet. You could also try disabling any software firewall, and / or running a packet sniffer on the other machine to see if the packet is actually being recieved by the machine but is being dropped by the OS or software.   ;  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.   ;  There is no real way around this apart from for the host to have the router configured to allow it, I think. If there was, then I suspect that commercial games would use it - as it is, pretty much every game requires a correctly set up router in order to be able to host behind it.   