[omniORB] omniINSPOA and bidir connections (omniORB4)

[Duncan Grisby]

On Thursday 31 October, "Ulf Stoermer" 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 --