c++11 - C++ IRC Client design -

i'm attempting write rfc 2812 compliant c++ irc library. having trouble design of client itself. have read irc communication tends asynchronous.

i using boost::asio::async_read , boost::asio::async_write. reading documentation have gathered cannot perform multiple async_write requests before 1 completed. therefore end rather nested callbacks. doesn't defeat purpose of doing async calls? wouldn't better use synchronous calls prevent nesting? if not, why?

secondly, if not mistaken, each boost::asio::async_write should followed boost::asio::async_read receive server's response commands sent. client's functions, therefore, need take callback parameter user of class may after client receives response (ex. send message...).

if continue implementing async, should keep std::deque<std::tuple<message, callback>> , each time boost::asio::async_write finished, , there tuple in queue, dequeue , send message raise callback? optimal way implement system?

i'm thinking since messages sent time i'm going have implement kind of listener loop queues responses, how associate these responses specific command triggered them? or in case response message channel user?

the irc protocol full-duplex protocol. such, 1 should listening server connection expecting commands process. argued 1 should use messages received server update state, rather correlating request , responses, server may not respond command or may respond later expected. example, 1 may issue whois command, receive multiple privmsg commands before receiving response whois. chat client, user expect being able receive chat messages while waiting response whois. hence, having async_write() async_read() call chain may not ideal in handling protocol.

for given socket, asio documentation recommend not initiating additional read operations if there outstanding composed read operation , not initiating additional write operations if there outstanding composed write operation. queuing messages , having asynchronous call chains process queue great way fulfill recommendation. consider reading answer nice solution using queue , asynchronous call chain.

also, aware server may send ping command on active connection. when client responding pong command, may necessary insert pong command near front of outbound queue gets sent out possible.