UDP question
Author
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?
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.
Author
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?
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!
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!
Author
this is exacly what I was talking about, but is there a better safe gard to this or is it is what it is?
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.
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.
Author
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?
is there a way to tell the router what local ip it needs to forward the data to?
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]
Author
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.
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
