If I understand right the Server can''t identify multiple Clients trasmitting behind firewall by IP and PORT. If that really so, I see two solutions. 1. Server gives each one of them different SOCKET_OUT port (and listening port of course). 2. Each one of the clients attaches to the message his ID. Are there any experienced methods of communicating of type Server <= = = => FIREWALL/ROUTER <=> Client ?

"If I understand right the Server can''t identify multiple Clients trasmitting behind firewall by IP and PORT."

I believe the client (IP,PORT) combination *will* be unique, even from behind a firewall.

Just because the client is connecting to port 80 on the server doesn''t mean the client port is 80. The client port is independent of the server port.

1. I''m sorry I didn''t mentioned that I am talking about UDP protocol here and there is no actual connection at all.

2. The way I see it when Server gets packet from client behind the firewall/router he (server) recieves an IP of the Router, not the client that send the data. Server replyes to Router''s IP and Client''s Port. Router translates the request to an internal (NAT) IP address.

If you use UDP and needs to identify the client in some way, information about who the client is must exist in the data of the packet. You cannot maintain an IP based "session" with UDP, use TCP for that.

* The recvfrom function receives a datagram and stores the source address.

int recvfrom(SOCKET s, char FAR* buf,int len, int flags, struct sockaddr FAR *from, int FAR *fromlen);

from [out] Optional pointer to a buffer that will hold the source address upon return.
(Platform SDK: Windows Sockets)

When recieving tha packet by TCP (with "recv") or UDP (with "recvfrom") "from" structure stores the source address.

quote:

---

Original post by Barabashka
* The recvfrom function receives a datagram and stores the source address.

int recvfrom(SOCKET s, char FAR* buf,int len, int flags, struct sockaddr FAR *from, int FAR *fromlen);

from [out] Optional pointer to a buffer that will hold the source address upon return.
(Platform SDK: Windows Sockets)

When recieving tha packet by TCP (with "recv") or UDP (with "recvfrom") "from" structure stores the source address.

---

Yes?

If you explain what you are doing, the nature of the traffic etc, it would be alot easier to understand your problem.

Red_mage is right. There is no connection with UDP, per se, but each packet is going to be tagged with an IP address and a source port. The two together will be unique for each client (even two coming from the same internal network). When a connection comes in, record the IP address and port and any time you need to talk to that client you use them to address your reply packets.

Most of the NAT routers out there (Linksys, etc.) seem to keep track of which internal clients (identified by IP and port) have sent requests to which servers. As long as a reply is received within a certain amount of time after a message is sent, the router will allow a reply from the same server. My initial testing has shown that after about 15 seconds the router will stop allowing responses until another message is sent. Normally that's not an issue since communication is incessant with most multiplayer games, but in some situations you may need to create periodic heartbeats on the client to keep the connection open.

bpopp (bpopp.net)

[edited by - bpopp on November 25, 2003 1:18:22 PM]