Messages

1

Network / SocketUDP::Receive

« 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.

2

Network / SocketUDP::Receive

« 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.

3

Network / SocketUDP::Receive

« 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

4

Network / SocketUDP::Receive

« 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

5

Feature requests / Threading primitives

« on: January 19, 2009, 07:43:45 pm »

Yeah, okay. I just figured with Thread and Mutex we're already 90% of the way there.

6

Feature requests / Threading primitives

« on: January 18, 2009, 07:22:27 am »

It would be nice to have an "Event" threading primitive in addition to Mutex and Lock. Without something like Event it's hard to efficiently implement a producer/consumer queue and several other nice things.

-- John