I haven''t started on my network code, but I think I will be using threads to handle the network layer. The idea is that the network thread can block without affecting the frame rate.

All data to be sent or received is placed into queues. For example, when a client wants to connect to the server, he will send a login message to the server. The server''s network thread will receive the message and throw it on the incoming queue. The main thread, the one doing the rendering will check the queue on each frame. It can process all or some of the messages in the queue. It could process a message, check the time and if it took to long to process, it can skip processing another message until the next frame. If the server wants to send a message to the client, it puts the message on the queue. The network thread will check this queue periodically and send any messages. The message class will need to have a parameter for the destination and source so that it can route it appropriately.

So much for my brain dump.


- onebeer

Here''s my NetEngine design :

4 threads :

Worker : The main one. Responsible for dealing (send/get) messages

Receiver : Alerts Worker when a new message arrived

Sender : Alerted by Worker when messages needs to be sent. Responsible to send to a client or all clients depending of the message type. Alerts Scheduler if secured messages need to be sent.

Scheduler : Alert Worker or the main prog it''s time to perform specific actions (secured message answer not arrived so send one more time the message, tells the main prog it''s time to send specific informations, tells the main threads messages are awaiting....)

all threads block with a GetMessag() call execpt Recevier who waits whit a select().


If you have questions, just ask.



- Iliak -

Threads make for programs that are harder to debug, and end up causing a LOT of synchronization overhead in almost all situations. You have to be really careful about design if you use threads. I''d suggest not doing it, if you have an asynchronous alternative.

If you use threads ONLY to lift away synchronous APIs, and post all results to a single message queue that actually does all application-level work, then that''s OK; that''s about the safest use you can make of threads.

When it comes to a networking library, how you structure the physical socket really doesn''t matter that much. How you pull data into the API, and how you deliver data back to the application, and whether you do merging, re-sends, re-order, etc is what matters. For example:

Most sockets APIs have "write" and "read" functionality. But that''s not really what you want. Ideally, you''d have a callback from the API to the application, saying "OK, there''s space for X more data now; please put in whatever you think is useful." Then your networking library immediately sends the result. If you provide a "write" abstraction, then typically the application will write data in bursts, which will sit in queues for undetermined amounts of time, adding latency.