Dec 252016
 

I recently ran into a bug where an asynchronous operation, namely boost::asio::async_write from Boost’s asynchronous library,  wasn’t completed before the next call to async_write was made. This results in not being able to guarantee the order in which packets are received on the other end of the socket (or even if all the data from the previous write makes it…?). For reference, someone else had a similar problem and posted on Stackoverflow.

Now the solution offered (and other people recommend the same thing it seems..) is basically to use a queue to manage the write operations, as is expressed in the Boost examples, This solution is lovely, but then you have to start worrying about things like:

  1. This queue could grow arbitrarily large
  2. It becomes more complicated to manage memory efficiently if you have multiple clients that need to receive the same data

Okay, maybe those aren’t so hard to deal with. However effort also has to be put into establishing a solid protocol. What happens if a client disconnects during a message? Do you cache until they reconnect? This depends on the demands of the client, but it’s obvious things get hairy quite quickly. Questions keep coming up for edge cases and your codebase expands….

I feel like these types of problems have been solved. Where’s the library I’m not using? Or is it just too hard to abstract away problems like this without being too rigid?

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

(required)

(required)