 |
|
 |
|
Next: what windows fans don't tell you about linux
|
| Author |
Message |
External

Since: Jun 06, 2009 Posts: 2
|
(Msg. 1) Posted: Sat Jun 06, 2009 1:49 am
Post subject: Ideas required for usage of sockets API for efficient network Archived from groups: comp>os>linux>development>apps (more info?)
|
|
|
Hi all,
I am evaluating various methods of using sockets API for a network
program to make it efficient. Your ideas are most welcome. (reference:
rstevens book)
For the purpose of our discussion lets take reference the following
definition of the programs:
1) The server handles multiple connections, the connections can be
many in no. (~20-50)
2) The server reads data from clients and writes data to clients.
3) The clients too read data from server and write data to it. This
and the point 2 imply there is a protocol between the server and
clients. The protocol mandates exchange of data in form of buffers
where each buffer has a fixed size header(X bytes) followed by
variable length payload(N bytes).
4) Both servers/clients are high bandwidth applications.
5) There exists some latency while processing data in servers and
clients (Z units of time)
6) The performance metric is low CPU consumption for Y no. of messages
in the system.
In my opinion such programs must use :
1) epoll API instead of select.
2) non blocking sockets for read/write. Non blocking for write
necessitates use of some efficient buffering mechanism of saving
partial writes. We must avoid memcopy here. Please suggest some
algorithms here.
3) Reduce the no. of reads of messages by using scatter read API.
However it is complicated as the data is always processed as header
+payload. How a read vector has to be setup I am unable to understand.
4) Reduce the no. of writes of messages by using gather write API. The
implementation becomes difficult if it is combined with non blocking
sockets and one has to handle partial writes.
Lets have a discussion on each of the above 4 points. Your algorithms
and ideas and any new points are welcome. |
|
| Back to top |
|
 |  |
External

Since: Jun 06, 2009 Posts: 2
|
(Msg. 2) Posted: Sat Jun 06, 2009 1:52 am
Post subject: Re: Ideas required for usage of sockets API for efficient network [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On Jun 6, 1:49 pm, saurabhth <saurab... DeleteThis @gmail.com> wrote:
> Hi all,
>
> I am evaluating various methods of using sockets API for a network
> program to make it efficient. Your ideas are most welcome. (reference:
> rstevens book)
>
> For the purpose of our discussion lets take reference the following
> definition of the programs:
>
> 1) The server handles multiple connections, the connections can be
> many in no. (~20-50)
> 2) The server reads data from clients and writes data to clients.
> 3) The clients too read data from server and write data to it. This
> and the point 2 imply there is a protocol between the server and
> clients. The protocol mandates exchange of data in form of buffers
> where each buffer has a fixed size header(X bytes) followed by
> variable length payload(N bytes).
> 4) Both servers/clients are high bandwidth applications.
> 5) There exists some latency while processing data in servers and
> clients (Z units of time)
> 6) The performance metric is low CPU consumption for Y no. of messages
> in the system.
>
> In my opinion such programs must use :
>
> 1) epoll API instead of select.
>
> 2) non blocking sockets for read/write. Non blocking for write
> necessitates use of some efficient buffering mechanism of saving
> partial writes. We must avoid memcopy here. Please suggest some
> algorithms here.
>
> 3) Reduce the no. of reads of messages by using scatter read API.
> However it is complicated as the data is always processed as header
> +payload. How a read vector has to be setup I am unable to understand.
>
> 4) Reduce the no. of writes of messages by using gather write API. The
> implementation becomes difficult if it is combined with non blocking
> sockets and one has to handle partial writes.
>
> Lets have a discussion on each of the above 4 points. Your algorithms
> and ideas and any new points are welcome.
One thing I forgot to add: The client/server programs use TCP/IP |
|
| Back to top |
|
 |  |
External

Since: Apr 25, 2007 Posts: 134
|
(Msg. 3) Posted: Sun Jun 07, 2009 6:31 am
Post subject: Re: Ideas required for usage of sockets API for efficient network [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On Jun 6, 1:49 am, saurabhth <saurab....RemoveThis@gmail.com> wrote:
> In my opinion such programs must use :
>
> 1) epoll API instead of select.
For less than 100 clients, you will probably see no measurable
difference between poll and epoll.
> 2) non blocking sockets for read/write. Non blocking for write
> necessitates use of some efficient buffering mechanism of saving
> partial writes. We must avoid memcopy here. Please suggest some
> algorithms here.
Why do you need to avoid memcopy? This sounds like odd premature
optimization.
> 3) Reduce the no. of reads of messages by using scatter read API.
> However it is complicated as the data is always processed as header
> +payload. How a read vector has to be setup I am unable to understand.
That won't reduce the number of reads. In fact, it well may increase
it.
> 4) Reduce the no. of writes of messages by using gather write API. The
> implementation becomes difficult if it is combined with non blocking
> sockets and one has to handle partial writes.
Why would your messages be spread out in the first place?
When you need to write a message, follow this logic:
1) Do we have any data already buffered for this connection? If so,
add this to the buffer and stop (we're already trying to send, so
nothing else to do).
2) Try to send this message. If we sent it all, stop.
3) Save what's left of this message to be sent next time. Add this
connection to the write set.
How you keep the write buffer is up to you. I recommend a linked-list
of fixed-size buffers. That helps you avoid large numbers of small
writes without needing a copy at write time.
DS |
|
| Back to top |
|
 |  |
External

Since: Apr 02, 2007 Posts: 158
|
(Msg. 4) Posted: Sun Jun 07, 2009 5:20 pm
Post subject: Re: Ideas required for usage of sockets API for efficient network programs [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
saurabhth <saurabhth DeleteThis @gmail.com> writes:
[...]
> For the purpose of our discussion lets take reference the following
> definition of the programs:
>
> 1) The server handles multiple connections, the connections can be
> many in no. (~20-50)
> 2) The server reads data from clients and writes data to clients.
> 3) The clients too read data from server and write data to it. This
> and the point 2 imply there is a protocol between the server and
> clients. The protocol mandates exchange of data in form of buffers
> where each buffer has a fixed size header(X bytes) followed by
> variable length payload(N bytes).
> 4) Both servers/clients are high bandwidth applications.
> 5) There exists some latency while processing data in servers and
> clients (Z units of time)
> 6) The performance metric is low CPU consumption for Y no. of messages
> in the system.
>
> In my opinion such programs must use :
>
> 1) epoll API instead of select.
Anything is better than select.
> 2) non blocking sockets for read/write. Non blocking for write
> necessitates use of some efficient buffering mechanism of saving
> partial writes. We must avoid memcopy here. Please suggest some
> algorithms here.
Why would you want to copy anything for this? In case of a partial
write, you adjust the number of bytes which still need to be written,
increment the write pointer before you call write again (possibly
after having been notified that writing without blocking is presently
possible). |
|
| Back to top |
|
 |  |
|
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|
 |
|
|