Hello James, Please find my comments below. 2010/1/10 James Mansion <james@mansionfamily.plus.com>
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