new to network programming

Quote:

Original post by Lode 1. While receiving or sending packets, is it possible to let the rest of the program continue (like drawing things and moving sprites around)? If so, how?

Yes. You can use things like multiple threads or asynchronous I/O. The best way to handle this depends on the architecture of your game engine. (And the question itself may imply a level of overkill.)

Quote:

2. Can SDL_net do everything needed for a multiplayer game?

I don't know of anything it's missing that would be necessary for a game.

Quote:

3. Is it possible to use packets of variable length? (e.g. a packet saying a player moved is shorter than a packet containing a long chat text a player made)

Yes, though you should account for that in your protocol.

Quote:

4. Is it possible to have *one* program that sends something to the network and receives it again?

I'm not sure I understand the question.

One solution is multithreading. Socket data packets vary in length, so you would continue reading the data from the stream (TCP) or message (UDP).

Kuphryn

4. Is it possible to have *one* program that sends something to the network and receives it again?

-- Tutorials usually only have a program that sends data and another that recieves the data the other sends. But yes its possible, Infact its highly likely you will have 2 way communication :P

One program can open two sockets, and send data between them. Or, one program could open a single UDP socket, and send data to its own address.

I suggest checking out the resources that the forum FAQ points at, by the way. Lots of good stuff in there.

Planet-source code is a good place to pick up some examples of source.(That's where I started [wink] )

How to use multithreading?

I'm using DevC++ and so far my code is platform-independent, is there a platform independent way to use multithreading.

Note that I'm programming the CLIENT, does the client need multithreading?

Do all multiplayer games use multithreading? Does Unreal Tournament use it, and if it doesn't, how does it manage to draw so many FPS while it has to wait for packets?

[Edited by - Lode on November 2, 2004 5:06:23 AM]

The network card and the OS layer will receive the packets and put them in system memory. When the application finds the time to issue a 'recvfrom()' call, the data is moved to the call's specified buffer.

You don't need multithreading to do networking. In fact, most games use non-blocking calls for this, especially for the client side. You are polling all inputs (mouse, keyboard, etc) in your game loop, and networking can be bundled there and considered as one more input channel your game simulation needs to take into account. Polling this way is not efficient, but who cares? The computer is completely dedicated to the game anyway.

You will find multi-threading on the server side, where the server must update multiple game states at different time intervals and efficiency is at a premium. The FPS and RTS genres don't go down this route, but the MMORPGs typically do because of the potentially large number of clients and the multi-CPU systems used.

> is there a platform independent way to use multithreading

Not really. The BSD socket API is implemented with little variation across platforms, but every OS has its own little perks when it comes to multithreading support. It depends on how optimized you want it.

-cb

Again, multi-threading may be overkill, but if you want to do it in a relatively platform independent manner several libraries provide thread wrappers. For example, SDL and boost both provide a way to use threads in a more or less platform independent manner.

Well, take the SDLNet_TCP_Open connect function (I'm using SDL_net).

If it can't connect, that function takes up like 30 seconds or so. 30 seconds during which the program does not respond, users can't close the program, nothing gets drawn to the screen, etc... and only after 30 seconds of nothingness the program responds again.

How can I let something else happen during those 30 seconds, and yet after 30 seconds be able to know that SDLNet_TCP_Open didn't manage to connect, WITHOUT multithraeding?

Thanks.

If you have to use SDL, and SDL does not have an asynchronous API, then you have to use threads to asynchronize it.

It's been my experience that making the least possible code run inside the actual other thread leads to the best designs, lowest locking overhead, and generally easiest to maintain code. A thread pool that accepts items on a work queue, and arranges to call back FROM WITHIN THE MAIN THREAD when items complete, is a pretty useful design paradigm when dealing with non-async interfaces.