Hey all, I want to make sure I understand this right before I start modifying my network code. My server listens on port 4829 and it sends out on port 4828. The clients, conversly, listen on port 4828 and send out on port 4829. These are all UDP datagrams going back and forth. This works just fine unless someone is behind a router or firewall. To this point, I''ve just told people that they have to open those ports to connect (or route them if they are NATted). Obviously, this isn''t ideal. Sometimes the players don''t have access to the firewall or router configuration (e.g. public machines), so I''ve already lost some testers because of this. So I want to open those ports semi-automatically from within the client program. Can I send out from the client two dummy packets, one on each port, to just open the route? The problem is the packet going out on 4828 from the client would never get to the server (it''ll bounce against my firewall). But that shouldn''t matter, right? As long as the client machine sees two packets going out to my servers IP address, it should then accept packets coming in on those same ports if they are from that same address, yes? Ron

When you say that the server listens on port 4829 and sends on port 4828, do you mean sends to instead? or sends to 4828 from 4828?

You shouldn''t really need to keep 2 sockets open for sending and receiving. Indeed, if you do, that means you can''t run the server and client on the same machine since they will have port conflicts.

Have the client only use 1 socket and send to the server at the server''s well known port. The server accepts the connection and acknowledges the client. If you are using TCP, you already have a full duplex connection using 1 socket at each end that you can send/recv. If you are using UDP, then the server should send back to the client address extracted from recvfrom(). Commonly, the server will open another socket and send the client a packet from the listening socket indicating the port of the new socket. This gives all clients their own separate port on the server and lets the well known listening port be free for waiting for incoming connections. You could always just use 1 socket on the server and multiplex the packets yourself.

This should also handle most NATs for the clients. You send from port A to server at port B. Server responds from port B, sending to client at port A. Client sends from port A to server at port C. Server sends from port C to client at port A.