Re: [boost] [asio] Pass some parameter to io_service::run

Subject: Re: [boost] [asio] Pass some parameter to io_service::run
From: Dmytro Ovdiienko (dmitriy.ovdienko_at_[hidden])
Date: 2010-01-11 10:38:02

Hello James,

Please find my comments below.

2010/1/10 James Mansion <james_at_[hidden]>

> Dmytro Ovdiienko wrote:
>
>> If number of sockets = 60 and worker_count = 4, I have only 4
>> incoming_buffers and 4 message_parsers.
>>
>> With Boost Asio I will have 60 incomming buffers. Though it is not a
>> problem. Buffer size is 64k. The problem is message_parser. It uses ~5MB
>> ...maybe more.
>>
>>  If you can currently get away with a parser bound to each worker, then
> why does that need
> to change when using asio?
>
>
This solution with parser bound to each worker works only with my home made
network library. I cannot repeat this with boost asio without TLS or
parser_pool. But I need boost::asio because it uses Completion Ports and I
don't want to repeat the same in my network library.

I have made some tests :

- synchronous send/receive operations on localhost using my library takes
20us
- synchronous send/receive operations on localhost using boost::asio takes
29us

- asynchronous send/receive operations on localhost using my library takes
64us
- asynchronous send/receive operations on localhost using boost::asio takes
24us

Looks like Completion Ports works better than select + queueing/dequeueing +
recv in user mode (not kernel). That is why I decided to move to asio.

I don't understand why you would have an objection to a permanent binding
> with TLS

TLS looks like global variables. Global variables violate encapsulation. I
suppose to support my program at least 2 years. I don't want to hate myself
two years :)

> or
> a temporary binding using a pool of parsers, since it seems that each
> datagram must be
> parsed entirely and then the parser reset for the next?

Exactly. But I don't want to create pool of the parsers. Access to the pool
should be synchronized. Synchronization eats CPU times.

> You said the parsers are stateful
> but I don't see how that can be without a great deal of pain with UDP as a
> result of packet
> loss or reordering.
>
>
State of the parser is reinitialized before every new message parsing. So
every new message is parsed from initial state.

> Those receiver buffers are large for UDP. Are you expecting packets to
> survive fragmentation
> reliably?
>
>
I read in the specification maximim UDP message size is 65k. I don't know
how it is possible but I did not think about this until now.

>  James
>
>