[omniORB] Optimizing call signature + performance

[Martin B.]

On 13.12.2010 16:49, Duncan Grisby wrote:
> On Tue, 2010-12-07 at 08:40 +0100, Martin B. wrote:
>
>> How large would I make these packets to transfer? When working on a
>> TCP/IP socket I'm (logically) just "streaming" data, or don't I? I
>> vaguely remember there being a maximum message size (maybe the term is a
>> bit different) for TCP/IP messages on Windows as well as some omniORB
>> setting relating to a max msg size ... ??
>
> omniORB's default maximum message size is 2MB. You can change it with
> the giopMaxMsgSize parameter.
>

Thanks for pointing this out! I may have been able to find the 
parameter, but I'm unsure if I'd contextualized it correctly :-)

> Since you want to stream data, it is possibly best to use oneway
> messages to avoid the latency of waiting for replies to come back from
> the server. ...

I'm unsure if I really want to avoid the latency at all.
If I understand this correctly, with a non-oneway call I can be sure the 
other party has finished processing the data I sent it so I can be sure 
that it makes sense to send the next (batch of) data.

I guess there's nothing for it but to test this, but if anyone has any 
opinion on the matter I would appreciate any further info.

> ... The risk with oneways is that when the first message comes
> in, a thread starts processing it; while it's still processing, the next
> message can arrive, and omniORB might dispatch another thread to handle
> it. There's an extension to omniORB that lets you prevent that, and also
> to enable Nagle's algorithm that can automatically batch data at a TCP
> level, which may or may not be helpful for you. Look in
> src/lib/omniORB/connections/README.txt for some details.
>

Awesome! Thanks! Good to know this is around.

cheers,
Martin