[omniORB] Oneway

Tue Nov 12 13:35:01 2002

Hi,

maybe somewhat late but I am just back from a conference, but we did
earlier this year some performance tests with oneway calls and omniORB
and orbacus and the conclusions were the following:
we did some 1 million oneway calls from a client to a server over a 100
Mbit/s ethernet (AMD 750 MHz machines) with 
in the call a long, double, boolean and string of 71 characters and did
the same test also as 'in' parameters.

Our hope was that multiple oneway requests could be put together in one
TCP segment and that this would be much faster.

The results are that, for omniORB client and server:
as in: approx.  150us per call
as oneway: approx. 22us per call

For orbacus client and server:
as in : 530 us per call
as oneway: 800 us per call

1) omniORB is faster, but this was already known :)
2) apparently omniORB can send more oneway requests in one TCP segment,
orbacus doesn't (don't know exactly why as a TCP socket is a stream in
fact).
3) orbacus has a very bad client oneway implementation: all oneway
requests are buffered in the client until e.g. a not oneway operation is
called or until the sending of oneways has stopped. Of course in normal
usage this has not much problems, but if you send continuously, then you
run first out of RAM memory and later out of virtual memory and the
machine can crash (even linux !). So this explains why the orbacus
oneway is slower than the in call (because some virtual memory had to be
used). So this happens also with an orbacus client and omniORB server.
4) in our tests, a oneway was never dropped
5) omniORB could send with this oneway IDL about 80 Mbit/s traffic on
the link (with TCP/IP headers and so included, thus not only
information)

best regards,
Brecht

Ulf Stoermer wrote:
> 
> Duncan, thanks very much for explaining in depth
> the issues with oneway calls, very enlightening!
> 
> I have one more question, please.
> You said:
> 
> > In the context of the original question about streaming audio and
> > video, neither of these would occur. The application would make sure
> > not to generate any LOCATION_FORWARDS, and since the network
> > connection would be in regular use, the server would not choose to
> > close the connection (another ORB might choose to close it, but
> > omniORB wouldn't).
> 
> For how long would omniORB keep open an unused connection?
> In our application I was thinking of using oneway calls for the update
> messages of an observer pattern. Our system would typically have
> long periods where nothing is happening but also sudden bursts of
> very high activity.
> 
> Cheers
> 
> Ulf
> 
> On Tuesday 5 November Duncan Grisby wrote:
> 
> > > you mention using oneway calls.
> >
> > Only in the sense of "you could use oneway calls but there are
> > problems...".
> >
> > > In their book, Henning & Vinoski completely discouraged people
> > > from using oneway calls because their reliability depends on the
> > > implementation of the underlying ORB.
> > > How good or bad is OmniORB in this respect?
> >
> > It's not really a question of what omniORB does -- any decent ORB has
> > the basically same behaviour and the same problems. It is often said
> > that a compliant ORB could choose to ignore all oneways. That is
> > technically true, but of course no ORB actually does that.
> >
> > There are several ways that oneways can be lost. They are artifacts of
> > the CORBA spec (and the real world), so there's nothing an ORB can do
> > to avoid the problems. There are two main ways to lose a oneway:
> >
> >   - The call would have resulted in a LOCATION_FORWARD reply to
> >     indicate that the object is elsewhere. The server just drops the
> >     call. (The server could do the forwarding itself, but that could
> >     be problematic for various reasons.)
> >
> >   - A race condition occurs with connection shutdown. At about the
> >     same time that the client makes a call, the server decides to
> >     close the network connection between them. While the request from
> >     the client to the server is in flight, the CloseConnection message
> >     and TCP shutdown packets are in flight the other way. Some time
> >     after the client sent its request, it notices that the connection
> >     has been closed. It has no way of knowing whether its request
> >     arrived or not.
> >
> > You could also lose a oneway if some sort of network error that would
> > normally result in an exception occurred, but in that case you would
> > probably find that it was broken on the next call.
> >
> > In the context of the original question about streaming audio and
> > video, neither of these would occur. The application would make sure
> > not to generate any LOCATION_FORWARDS, and since the network
> > connection would be in regular use, the server would not choose to
> > close the connection (another ORB might choose to close it, but
> > omniORB wouldn't).
> >
> > On the subject of oneways, the Messaging specification adds so-called
> > "reliable oneways" that supposedly solve these problems. They do, but
> > only in a way that means they aren't particularly useful any more. The
> > policy that guarantees delivery is sync_with_server, meaning the
> > client waits for a reply to indicate that the request reached the
> > server, but it doesn't wait for the server to actually perform the
> > method. That means you never lose a request (unless the server
> > crashes), but it also means you have lost the benefit you were using
> > oneways for in the first place, which was to allow the client to
> > continue processing without being bound by round-trip network latency.
> >
> > Cheers,
> >
> > Duncan.
> >
> > --
> >  -- Duncan Grisby         --
> >   -- duncan@grisby.org     --
> >    -- http://www.grisby.org --
> > _______________________________________________
> > omniORB-list mailing list
> > omniORB-list@omniorb-support.com
> > http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >
> _______________________________________________
> omniORB-list mailing list
> omniORB-list@omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list