I'm using tcp.
The main data that is lost is move request. When one client send a move request the rest are lost.

piccolo, that's not because of multithreading, your program is broken.

I've written console application chat programs that were not multithreaded, and chatted with several users on a network, and/or several fake users on the same machine as the server -- it all worked fine, no multithreading, no data loss, TCP of course.

edit: the way tcp is implemented is that it has it's own buffer, so your application does not need to be multithreaded -- if you wait 5 seconds to read the data, it should still be there. /edit

UDP on the other hand, you can expect packet loss, especially if you're saturating the network with UDP packets...

It sounds like a bad design to me...

Why cant you just poll the network for messages in your game loop?

Because when his app is backgrounding it is not running yet.

The app just 'hang' until it get focusing again.

If only he had rode me correctly and did some search as I told.... I finally second Michael Jensen about the design thing.

Try to add this in your initialization routine:

if (set_display_switch_mode(SWITCH_BACKGROUND) != 0)
{
    fprintf( stderr , "Warning: can not change switch mode to SWITCH_BACKGROUND ");
    if( set_display_switch_mode(SWITCH_BACKAMNESIA) !=0)
    {
        fprintf(stderr,"Error: can not change switch mode to BACKAMNESIA");
        return FALSE;
    }
}

You are just now telling me that.

You do not check its return value. How do you know you are really using a good switch mode ?

Is it configured on both client & server ?

SWITCH_BACKAMNESIA works fine in fullscreen while SWITCH_BACKGROUND works in windowed mode.

If all the previous things are ok, it is your implementation who is buggy.

So, uh, you are going to duplicate what TCP is already doing, only worse?

Just make it work like you have it. TCP does not drop packages (it drops the connection if a certain package takes to long to reach it's destination).

JH is right, TCP will not drop your packets -- I've run a console server app, and an allegro app (of my own design) side by side on the same machine, and not had any problems thus far, and have even tested in on several machines, and networks...

You start the console app, let it serve clients, start a client, and connect. -- If the connection becomes unstable, the TCP connection will disconnect, the-end.

It will never drop, lose, re-order, or scramble your packets; if it absolutely needs to, it just terminates your connection.

The OS is multithreaded so your apps don't need to be, though having them not take 100% of the cpu usage in a wait loop as discussed earlier is nice. If the OS wants to do something, it does it, without asking permission, it will yank the thread away, process the TCP/IP stack, and then give the thread back in it's own sweet damn time.

There's something wrong with your program or your understanding of network programming.

Edit:
set_display_switch_mode has nothing to do with other programs running in the background, it only effects how your graphical application behaves in regards to when it has focus -- I suppose it could make the program actually suspend while it's minimized if it's set wrong; If your dedicated server is graphical (and it shouldn't be) this might be why your program doesn't work (ex: you're trying to run two graphical programs at once that are both vying for system/vram bitmaps and/or locks to such... -- that's kind of a no-brainer), and there may be nothing you can do, but to design it differently. -- there's no reason a dedicated server should be graphical... if you want to view the game in progress, etc, you should create a graphical client that connects to the dedicated console server.

Edit: Also in windows, I'm not sure that you can run two seperate applications at once that use the same implementation of allegro timers. But I might be mistaken.

Edit: And I'm pretty sure that any calls to vsync() will block indefinitely while your app is minimized, etc, etc... this is a bad design, just dont do it -- use a console app, a service, or a windows GUI app as your dedicated server.