[omniORB] Oneway

[Ulf Stoermer]

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
>