I am starting to implement my client/server architecture. Basically, there are two ways of doing what I want: 1. Check all sockets, periodically, until we get activity to one (or more) Read the data from that socket, and process it. If necesary, send update to clients right now, as we parse the data. OR 2. Check the sockets for data, until we get activity. Read the data, and put it in a buffer, for each client After we read all the sockets, process the data, and put every updates in client''s output buffer. After we read all the sockets, and processed all the data: Flush the output buffers (send the updates to the clients) Now, the question is: Is the first method more bandwidth consuming, since we send more TCP/IP packets? Which way would you do it?

It will depend on a couple of things.
1. Are you using TCP or UDP.
2. If using TCP do you have the Nagle algorithm disabled.

If the answers are "TCP" and "No" then unless your server is very slow, it will not make much difference to the number of packets sent as the nagle algorithm will delay sending until it has enough data for a decent packet size.

If the answers are 1."UDP" or 2."Yes" then it will make a difference to bandwidth.

Personally, the way i am currently doing my network engine, is closest to your 2nd way. It seems (to me) to be a much neater way of doing it.

I am using TCP, because UDP is too... complicated. I mean, I DO want my packets to actually arrive, or, if they don''t, I need to be notified that they didn''t.
Nagle? What''s that? I don''t know if it is disabled or not, it''s in the default mode, I guess. I am using SDL_net for all my networking code, BTW (I want a portable server).

I would take a guess that SDL doesn''t disable the nagle.