Clever Geek Handbook

Is there a "good" way to handle reassembling multicast from multiple sources?

I am currently reworking our existing proprietary socket wrapper code to use boost asio so that it can do some heavy lifting for us. Perhaps the most complex area of ​​our existing code is the multicast handling code. The code allows our mid-range servers (of which there may be many of me on the same system) to send multicasts to client mailboxes, which use them to provide updates to system users.

The reason the code is complex and error prone is because it uses multiple raw buffers to reassemble the multicast streams depending on where they came from. It looks like even with Boost.Asio I will have to deal with this same problem, so before I got stuck I thought it might be worth asking how other people have dealt with this situation.

It looks like this is a very common use case. Is there anything that can help me get this job done without the code I currently have? Or is there an established C ++ template (Boost or otherwise) that can do this kind of work?

Obviously I could make it easier for myself and use STL containers for packet buffering instead of raw arrays, but this code should be really high. On large installations there are a huge number of packages and it should respond as close to real time as possible.

Thanks in advance for any thoughts on this matter.

Jamie

0


source to share


1 answer


It doesn't seem like you've given enough information for detailed answers, but there are a few general pointers to consider when processing real-time multicast data.

  • If you are using raw UDP multicast, you are probably running some sort of user-space protocol sequence to deal with lost or duplicated packets. No matter what kind of optimizations you want to do, resist the temptation to break the layers between your application and your protocol layer.
  • std::vector

    , for most purposes, is identical to a raw dynamically allocated symbol buffer. Don't shy away from using it just because it is an abstraction layer. However, there are two cases where you should avoid doing this:
    • If you can get away with statically allocated buffers
    • If you need to transfer ownership of the buffer downstream (although if you elaborate carefully it swap()

      may be sufficient)
  • Prepayment is your friend. If you can have a set of buffers available for use as you enter data, you can remove most dynamic allocations from the fast path.
  • Minimize memory copies. If you can handle data in the same call stack, you have a chance to avoid copying. If you need to transfer data to another stream, you may be forced to copy the data.
  • If your application can handle blocked buffers (instead of combining all data into one buffer), look at writev

    and readv

    .


I don't believe any canned solution will solve your problems. Boost ASIO, libevent

etc. Will handle socket abstractions for you, but what you do with your data is still your responsibility once it's delivered.

+2


source






More articles:


All Articles