sendin to specific client with udp
Author
I want to reply to a client after I receive a packet from them but what I'm trying isn't working. I have them both set up on the same port. Right now I have the client send a packet and I get it with recvfrom. and store who it's from in a sockaddr_in structure. Then I set the original sin_addr I set the server connection up with to the sin_addr from the from structure but what's happening is that the server is just sending the packet to itself since both the client and server are running on the same machine. Anyone know how to fix it so my client gets the packets my server sends?
It's been a long time I worked with networking stuff. As far as I remember, you shouldn't set up the client on any specific port. Let the system decide the client port.
It is possible to have the client and the server on the same machine.
The information given to you by recvfrom() should include a client's address and port. If you send back to the same place you got it from that should work.
Quote:Original post by etsuja
if I don't set the port on the client the packet never makes it to my server.
This sounds like an overzealous firewall. You need to ensure the port is open and forwarding to the server.
It's a REALLY good idea to let the system assign UDP port for outgoing connections. This allows you to run multiple clients on the same machine (useful for debugging) without getting into complications as to which send came from which client.
Read up the man pages for sendto(...) and recvfrom(...). What you get from recvfrom(...) on your server is what you should sendto(...) from your server. On your client recvfrom(...) should give you the IP and port of your server, which should also be the only thing you ever send to, unless you're building a peer-to-peer system. You should store these addresses on a per-client basis (identifying client primarily by IP AND PORT), not anywhere else.
Author
If my server is bound to a specific port and my client doesn't specify which port to send data to how will the server get the data sent to some random port specified by the client?
I think we're saying it's a bad idea to use bind() on a UDP socket on a client machine. Clearly, you have to use it on the server.
bind() tells the machine what port it should listen on (and send FROM).
sendto() tells the machine what remote port it should send to.
You can also use connect() to say what remote port to send to, but then you can't re-use that socket for other ports later.
bind() tells the machine what port it should listen on (and send FROM).
sendto() tells the machine what remote port it should send to.
You can also use connect() to say what remote port to send to, but then you can't re-use that socket for other ports later.
Author
I wasn't binding on the client... Do I need to in order for it to receive anything? And if I don't how do I receive anything with the client?
No, you don't need to bind on the client.
When you create a UDP socket it has a port assigned by the system, if you use that socket to send (sendto) the port it sent on is held open, and you can receive on it. The port number doesn't change from send to send.
So all your server has to do is store the IPs and ports of the clients that connect to it to tell them apart. Don't rely on a certain port source for authentication.
When you create a UDP socket it has a port assigned by the system, if you use that socket to send (sendto) the port it sent on is held open, and you can receive on it. The port number doesn't change from send to send.
So all your server has to do is store the IPs and ports of the clients that connect to it to tell them apart. Don't rely on a certain port source for authentication.
Quote:Original post by _winterdyne_So all your server has to do is store the IPs and ports of the clients that connect to it to tell them apart. Don't rely on a certain port source for authentication.
Apparently NAT can sometimes change the port used to forward packets from a client. It is a good idea to also include some information in the packet which you can use to relate the incoming packets to an known client.
Talking about binding/not binding for UDP, I have a couple of questions too:
Is it possible to know which port the socket got assigned to if you leave it up to the system?
For TCP, when two processes bind to the same port, the second one will fail because the port is already in use. I haven't seen that happen for UDP - is is supposed to be that way, or can I set something to make sure the second bind will fail (which is what I want) ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
