[omniORB] Latencies - Oneway vs. Roundtrip

[Jens B. Jorgensen]

Helge Penne wrote:

> "Jens B. Jorgensen" wrote:
>
> > Helge Penne wrote:
> >
> > > Woha!  I started using CORBA to get away from all this low-level stuff.  This is a bit
> > > beside my field of competence...
> > >
> > > I've now traced the control flow from the proxy object and all the way down to the NT
> > > WinSock "send" function.  So far, it does not seems that omniORB does any buffering of
> > > oneway calls.  That should indicate that the buffering is done by the Windows NT socket
> > > implementation.
> > >
> > > The problem would thus seem to be the WinNT sockets use buffering by default.  My guess
> > > would be that the problem could be fixed by changing the socket options to
> > > "TCP_NODELAY", and that this modification could probably be done by adding the
> > > following statements to tcpSocketMTfactory.cc, line 834 (just after the "if (sock =
> > > socket(...)...)" block):
> > >
> > >     BOOL bNoDelay = TRUE;
> > >     int nResult = setsockopt( sock,  IPPROTO_TCP1, TCP_NODELAY, &bNoDelay, sizeof(
> > > bNoDelay) );
> > >     // Code to check the return value should be added...
> >
> > Close, but you misread the documentation. The '1' following IPPROTO_TCP is a footnote
> > indicator which states that IPPROTO_TCP is for backwards compatibility with WinSock 1.1.
> > You should use SOL_SOCKET. Also, the optval parameter is supposed to be a pointer to an
> > integer (set to 1 in this case), not a BOOL.
>
> I was wondering why they had used a different font for the "1"....  ;-)

Yeah, couldn't they have used that little dagger symbol or something?

> However, my version of the documentation (Visual C++ 5.0) does not list TCP_NODELAY under the
> SOL_SOCKET heading, only under IPPROTO_TCP.  The way I read this the second parameter should
> be IPPROTO_TCP.  Curiously, the documentation states that IPPROTO_TCP has been kept to
> preserve backward compatibility with winsock 1.1, but does not mention if it has been
> replaced with something else(!).

Yeah. The Linux docs for setsockopt say

       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).

So perhaps IPPROTO_TCP is defined to be the correct protocol number. I don't use this option in
any of my windows socket code so I couldn't comment from personal experience.

> It also explicitly states that the optval (fourth parameter) should be const char* pointing
> to a BOOL value.

Hmmm. I've got the Jan '99 MSDN and it sez:


     There are two types of socket options: Boolean options that enable or disable a feature
     or behavior, and options that require an integer value or structure. To enable a
     Boolean option, optval points to a nonzero integer. To disable the option optval points
     to an integer equal to zero. The optlen parameter should be equal to sizeof(int) for
     Boolean options. For other options, optval points to the an integer or structure that
     contains the desired value for the option, and optlen is the length of the integer or
     structure.

>
> Is your documentation different from mine, or am I getting tired and should go home to rest?
> ;-)

I'll let you be the judge!

--
Jens B. Jorgensen
jjorgens@bdsinc.com