So, I'm trying to get a basic client-server setup working. I have looked at the provided example, but the server simply waits until it gets a request, responds, and then it will close at the next bit of user input.Read this (http://sfml-dev.org/tutorials/2.0/network-socket.php), all the way at the bottom.
I would assume that the only way to solve this is for both the client and server to have separate threads for listening for connections.After you read the above, you should know better.
Server :You will kill yourself with the synchronization you would need to perform for such a simple task. Unless you expect to handle a really big physics scenario or expect more than 20 clients to be connected at the same time, just use a single thread.
-Has two threads, one for Listening/Processing packets, and one for constantly simulating physics.
-If it receives input, it makes this change in a thread-safe buffer that is available to the other thread.
-If it receives any information requests, the listener responds with the requested info.
-Server updates all clients with updated physics states at a regular interval.
Client:Read this (http://sfml-dev.org/tutorials/2.0/audio-sounds.php). You will find this remark:
-Has three threads, one for listening to the server, one for drawing graphics/game logic, and one for audio.
-There is a physical state buffer that is always updated on a regular interval with information from the server. this stores information about the entities that should be watched as they aren't at rest.
-On the client, it seems that it requires at LEAST 3 threads, but what happens if your processor only supports 2 threads?You need to read up a bit about what a thread really is and how it is realized. Even before multi-core processors became mainstream, operating systems already let you create as many threads as you wanted until you ran out of system resources.
-Even if the computer can still handle all the threads, is one thread for networking enough? What if I need to send a packet to the server, at the exact time that the server is trying to send me a packet? Are both of our packets lost?If this were true, it would defeat the purpose of full-duplex ethernet and the internet would probably not work as it does nowadays. There was a time, in the last millennium, where such "collisions" could occur, but they were completely transparent to the application developer. You really don't need to worry about this. Sockets are able to do many things at once, UDP sockets are even able to send and receive from multiple hosts all at the same time.
Also, I'm not running simulation on every computer. I'm planning on just sending user input to the server, and receiving back any changes based on that input.You always need to have some kind of minimal physics system on every host if you want the simulation to appear smooth. Between updates, you need to keep predicting the next simulation state in order to update your graphics/audio. If you do this only every time an update arrives, you will end up with a very "choppy" simulation.
Or maybe I could just give them binary1248's PM box link... ;DPlease don't, binary has promised to work on SFG soon. >:( ;D
I was using them to ensure that my program didn't get stuck. Would you recommend I put a wait time on a selector? I just don't want to wait too long since you don't want a game to fall 1 second behind.Just set them to wait for 1 microsecond. That way it will run at (theoretically of course) 1000000 FPS maximum IF nothing else contributes to frame time, and I am sure there are many things that do so to much greater extents ;).
Do you know of a way to solve this issue using TCP?You don't have to solve this for TCP, because well... this problem is inherent only to UDP. The reason why UDP hole punching is needed, is because UDP is not a connection based protocol such as TCP. A NAT does it's magic mostly through mapping external port numbers to internal addresses so that it can track each connection and only has to expose its external address to the internet pretending it is the one from which all data originates.