nrtb-core team mailing list archive

[George Jordan <question147131@xxxxxxxxxxxxxxxxxxxxx>]

Question #147131 on New Real Time Battle changed:
https://answers.launchpad.net/nrtb/+question/147131

    Status: Open => Answered

George Jordan proposed the following answer:
I am having reservations about MUSCLE.  The part that "scares" me is the
part about the speed of service.

********** From the web page **************************************************
"Is TCP stream communication fast enough for my app? Do I need to use lower level protocols such as UDP or ICMP?
MUSCLE does all of its data transfer by serializing Messages over TCP streams. If your application is a particularly high-performance one (such as video streaming), MUSCLE may not be able to provide you with the efficiency you need. In this case, you might use MUSCLE TCP streams for your control data only, and hand-code separate routines for your high-bandwidth/low-latency packets. I've used this pattern (TCP + UDP) in audio-over-Internet programs before and it works well.

In addition, you should be aware of the CPU and memory overhead added by
MUSCLE to your communications. While MUSCLE has been designed for
efficiency, and will not make unreasonable demands on systems that run
it, it is necessarily somewhat less efficient that straight byte-stream
TCP programming. Specifically:

Its use of Messages means that there will be several dynamic allocations and deallocations, and an extra data copy, for each message sent and received. (note: ObjectPools are used to minimize the former)
It uses arbitrary-length message queues to avoid ever having to "block" your application's threads. While this will keep your application reliably responsive to the user, it can potentially use a lot of memory if you are producing messages faster than the network connection can send them.
If you use the MessageTransceiverThread class there will be one extra thread used for each MUSCLE TCP connection. In addition, MessageTransceiverThread (and the muscled) uses select() to arbitrate data flows, which can be inefficient under the currently released (R5 and earlier) BeOS networking stacks. (it's more efficient under other operating systems, and should be fine under BONE as well)"

****************************************************************

If you can explain how this is not an issue/problem for us, then I would
feel better about it.

-- 
You received this question notification because you are a member of NRTB
Core, which is an answer contact for New Real Time Battle.