Jump to content
  • Advertisement
Sign in to follow this  
betteroff

UDP question

This topic is 4369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a question about udp. in tcp/ip sockets there connected udp is a conectionless socket so my question is if your client is on a home network behind a router how does the server know what computer to send the packet to?

Share this post


Link to post
Share on other sites
Advertisement
When you send data using UDP, you typically use sendto() (not send()). The address given in sendto() is where the data should be sent to.

Share this post


Link to post
Share on other sites
I guess I should of been more clear, because generaly you dont bind a socket to listen and lets say you have 2 clients connected from one ip on a network, on the server when a message is read you pull the ip/port info from the datagram and send that data back how does the datagram know what computer to go to?

Share this post


Link to post
Share on other sites
I'm also having a bit of trouble determining your question, but I think you're asking about the situation where there's a server on the Internet somewhere and you're on a LAN behind a firewall. I think your question is "how is the server able to send a UDP packet to the client, since UDP is connectionless and the router should therefore not know the appropriate destination?" Feel free to correct me if I'm wrong.

The answer is that routers use a bit of guesing and a bit of magic. Specifically, routers know that although UDP is connectionless, an outgoing UDP message will most likely have a reply come back, so they'll create a temporary mapping between that client/port and that server/port as if there was a real TCP connection. That connection will die off in about 30 seconds or so, depending on the router.

Let's say a client opened two ports, say 1025 and 1026, and sent a message to the server from 1025. The router will change that packet's port to some other number, most likely, say, 2025. The server will get a message from the router's address and port 2025. If it replies to 2025, the router will remember that "connection," change it to 1025, and send it to the right computer and port, but if the server tries to send it one port higher, 2026, the firewall will probably just drop it, even though the client's 1025 has a port open right above it.

Think of the outgoing UDP packet as punching a small hole through the firewall on its way out. The return message just goes back the same way.

Hope that helps!

Share this post


Link to post
Share on other sites
I'm not sure I understand what you mean by safeguard. That the firewall lets incoming traffic come back is a feature. Are you asking how to ensure the router will not cut off communications at some point? If that's your question, the answer is you can't be entirely sure, but as long as you're regularly sending data, it should be alright. Just make sure that for every pair of client/port and server/port that will communicate, the first packet travels from the client to the server.

Or maybe you're asking if letting these packets come back is a security risk? I'd say that it is not, but if you worry that it is, most routers let you disable UDP connections.

Share this post


Link to post
Share on other sites
sorry if im not being clear what I was trying to say was is there a way to stop a router from droping udp packets.
is there a way to tell the router what local ip it needs to forward the data to?

Share this post


Link to post
Share on other sites
Quote:
Original post by betteroff
is there a way to stop a router from dropping udp packets.

No, not if the packets are unsolicited. NAT routers are supposed to drop all unsolicited packets. There is no way to prevent a NAT router from doing this. (Well, that's not entirely true, but it's a router setting that the user would have to change, not something you could control. Unless of course they had foolishly left UPnP on.)

Quote:
Original post by betteroff
is there a way to tell the router what local ip it needs to forward the data to?

No. However if the packets are NOT unsolicited, ie. the user has requested the connection, then a NAT router will automatically take care of routing the packets to the correct computer.

Quote:
Original post by betteroff
if your client is on a home network behind a router how does the server know what computer to send the packet to?

It doesn't. It only knows to send it to the router, and the router knows which computer to send it to.

The client requests a connection with the server and the NAT router sees two things, the local IP of the computer that requested the connection, and the server IP that the request was sent to. The NAT router will now allow incoming packets from the IP that the client sent it's request to, and will automatically rout those packets to the computer that requested the connection in the first place.

[Edited by - dwelty on October 4, 2006 12:48:17 AM]

Share this post


Link to post
Share on other sites
so basicly when dealing with udp datagrams its up to the client to continue the transfer of data, meaning you cant server side run a continuing loop to send datagrams to clients, its more of a responce system.

Share this post


Link to post
Share on other sites
datagram: a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.

When the client is behind a NAT router (and has not explicitly opened any ports), a server can never send packets to the client without an earlier exchange. The reason for this is exactly what is indicated in the definition, it doesn't have enough information. It doesn't know the IP of the client computer (and it never will, it will only know the IP of the client's router), and even if it did, it would do no good because the client IP is non-routable. Only the client's own router can direct packets to the client.

Therefore, the server's only option is to send its datagram to the client's router. The problem here is that while the router can receive the packet without any previous communication, it won't (without previous communication) have a clue what to do with it. There may be any number of computers behind the router, and it has no way of knowing which of them the packet was meant for, so the router simply drops it.

The only way around this is for the client to first send data to the server. This creates a mapping in the router specifying which client computer requested a connection with which server. Now, when the server sends data back to the client's router, the router will see that mapping, recognize the server's packet as being meant for a specific client behind it, and forward the packet on to the correct client.

What this means is that you can handle TCP/IP, or UDP, or any other protocol as you normally would if there was no router in the middle, *except* that the client *must* initiate. As long as the client initiates the conversation, you can handle things as if there was no router. It should be completely transparent.

[Edited by - dwelty on October 4, 2006 5:24:25 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!