Author Topic: SocketUDP::Receive (Read 17224 times)

Hoff · « **on:** January 22, 2009, 04:23:15 am »

Is there a reason SocketUDP::Receive does not take an "unsigned short & port" in addition to the "IPAddress &"? This would be quite useful and I know the data is in the underlying sockaddr_in.

-- John

Laurent · « **Reply #1 on:** January 22, 2009, 08:01:09 am »

The port is knows after data has been received from someone. What would it mean to pass it as a parameter of the function?

Hoff · « **Reply #2 on:** January 22, 2009, 04:22:55 pm »

Sorry, I think my question wasn't clear. The signature for SocketUDP::Receive is:

Socket::Status sf::SocketUDP::Receive(Packet & PacketToReceive, IPAddress &address)

The method is filling in "address' because the return parameter is being used to inidicate the status of the operation. The problem is that "address' is only an IP address, while it would be very useful to have the port the data was sent on also. This information is in the sin_port member of the sockaddr_in struct.

-- John

Tank · « **Reply #3 on:** January 22, 2009, 04:55:39 pm »

The destination doesn't change, therefore it's not necessary to append it to the parameters list. The IP address does change depending on the sender, so does the packet, but not the port. You can easily keep track of it by yourself.

Hoff · « **Reply #4 on:** January 22, 2009, 04:58:46 pm »

No, SocketUDP::Receive is a wrapper around recvfrom, which returns the address of the packet SENDER, not the receiver. Therefore both IPAddress and port can be any arbitrary value: just because the packet is going TO port 1234 doesn't mean it came FROM port 1234.

Tank · « **Reply #5 on:** January 22, 2009, 07:35:07 pm »

Okay, I get the point now. Thought you were asking to get the destination port as a parameter for the receiver.

Isn't it impossible to properly reply to an UDP packet currently? I mean, when a peer sends an UDP packet to server.org:1234 from client.org:4958, the server must be able to reply exactly to client.org:4958 so that NAT works. Else the client would have to forward a special port. Is this what you're actually asking for?

Hoff · « **Reply #6 on:** January 22, 2009, 07:48:03 pm »

Well, it's pretty annoying but you can do it. Read about the STUN protocol, and especially the part about the different kinds of NAT. The jist of it is that there are some devices that will always map the same IP:port of a UDP packet to the same external IP:port, and will also forward incoming UDP packets to the correct internal host if it has seen packets from that host in the recent past.

But yeah, sometimes you're just screwed and need to fallback to TCP.

Iscandel · « **Reply #7 on:** January 23, 2009, 02:29:08 pm »

I've already spoken about that on the french forum ( http://www.sfml-dev.org/forum-fr/viewtopic.php?t=1278 ) and I agree with you. Getting the UDP source port is useful.

Laurent · « **Reply #8 on:** January 23, 2009, 04:09:32 pm »

Ok, I understand and I agree

I had previously planned to change the UDP sockets API, to allow for connections. I think the modifications will then be bigger than expected.