[omniORB] Latencies - Oneway vs. Roundtrip

[Jens B. Jorgensen]

Helge Penne wrote:

> Jim Redman wrote:
>
> > Thanks to the group and Helge for the proposed solution.
> >
> > At 06:44 PM 4/13/99 +0100, Sai-Lai Lo wrote:
> > >I think it has been pointed out already that we do not set TCP_NODELAY by
> > >default. You probably want to play with setsockopt to see if the behaviour
> > >changes.
> > >
> > >From my admittedly narrow point of view I can't think of a use for oneway
> > where latency is not important.  If I was simply trying to move a large
> > amount of data and didn't care about latency I probably wouldn't send out a
> > bunch of small messages.  I use oneway because I need each tiny piece of
> > data to arrive as soon as possible after it is generated.  If this is the
> > normal reason then I could make a case for TCP_NODELAY being the default.
> >
> > Jim
>
> I'll second that.  I think the omniORB deserves a startup option that will let
> you turn this behaviour on or off.
>
> As to the proposed solution: Not that it was NT specific, and may not work on
> other platforms.  As Mr. Jørgensen pointed out, level=SOL_SOCKET should
> probably be used on other platforms.  Om my NT 4.0 computer, SOL_SOCKET does
> not work (gives no error, but no chance in behavior either).  This would
> indicate that a portable solution would have to use some #ifdef <platform>
> switches to make it work across different platforms.  I guess Microsoft's API
> could be to blame.
>
> - Helge

Well, I may have to recant since the documentation (at least in Linux) indicates:

       When manipulating socket options the level  at  which  the
       option  resides  and the name of the option must be speci­
       fied.  To manipulate options at the socket level, level is
       specified  as  SOL_SOCKET.   To  manipulate options at any
       other level the protocol number of the appropriate  proto­
       col  controlling  the option is supplied.  For example, to
       indicate that an option is to be interpreted  by  the  TCP
       protocol,  level  should  be set to the protocol number of
       TCP; see getprotoent(3).

It may be that in Linux using the SOL_SOCKET would work but it would seem that
passing the correct protocol identifier would be the right thing to do. Perhaps
the most portable (or not?!) would be to take the suggestion here and use the
protocol number returned for TCP from getprotoent().

--
Jens B. Jørgensen
jjorgens@bdsinc.com