Archived

This topic is now archived and is closed to further replies.

UDP architecture

This topic is 4986 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm starting my UDP network library and I need confirmation on my design before continuing, to make sure I'm on the good track... Here's the 2 main classes: NetDriver : - Responsible for initializing winsock. 2 main functions: Listen(port) and Connect(IP, Port). Both returns a new NetConnection. NetConnection : - For clients, responsible of handshaking with server (login), maintaining connection status, sending and receiving data. - For server, responsible of handshaking with clients (authorize login), maintaining connection status, sending and receiving data. Each frame, I update all connections, which calls recvfrom() and handle incoming data. Sending data is done with sendto(). On both server and clients. Is there a flaw in the design? Is it THE way to to basic UDP stuff? I'm new to network programming, so be patient! Thanks, Jean-Francois [edited by - deks on April 21, 2004 8:09:16 PM]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 -

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites