[ace-users] Re: questions re 'oneways' and CORBA Messaging
Douglas C. Schmidt
>> Is it possible to achieve TCP-like semantics for unidirectional,
>> opaque data transfer in CORBA?
Sure. There are several ways.
>> Yes, I know that I could open do this on plain, old TCP sockets,
>> but it seems to me that it should be possible to achieve something
>> similar (albeit with a bit more overhead) using CORBA.
Right.
>> My read of the CORBA Messaging spec is that using a 'oneway' and
>> the QoS SYNC_WITH_TRANSPORT policy should achieve what I am looking
>> for (assuming IIOP): i.e. client blocks if flow controlled; client
>> notified (though perhaps not immediately) if connection is dropped;
>> once data is accepted by the ORB it is guarenteed to make it to the
>> remote object reliably, sequenced, etc, assuming connection and
>> remote object are "up". Is this right?
Yes, that's correct.
>> A second question concerns what happens if the server for a
>> persistent object goes down and then comes back up. Using TAO 5.1.2
>> I noticed that when the server goes down, the client gets TRANSIENT
>> exceptions. This is what I might expect. However, when the server
>> comes back up the exceptions disappear but the remote object does
>> not get the data.
Are you making sure to bind stuff to the same port via the
-ORBendpoint option?
>> My last question concerns the behaviour of SYNC_NONE. Using TAO
>> 5.1.2 I noticed that it was possible to flow control (i.e. block)
>> the client on a oneway call. (I acheived this by suspending the
>> server) Yet, my read of the spec suggests this should never
>> happen. Is this a bug, or is my read of the spec incorrect.
You're reading of the spec is "incomplete". There's nothing in the
spec that requires an ORB not to block if it encounters flow control
on the underlying TCP connection.
Take care,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor TEL: (949) 824-1901
Dept of Electrical & Computer Engineering FAX: (949) 824-2321
616E Engineering Tower WEB: www.ece.uci.edu/~schmidt/
University of California, Irvine, 92697-2625 NET: sch...@uci.edu
Douglas C. Schmidt
>> Unfortunately, it's not. :-(
Oops, you're right. I was addressing this from the TAO implementation
perspective, which I believe will meet Jim's QoS requirements. This
isn't portable, of course. But then again, why use any other ORB? ;-)
Jonathan Biggar
>
> Hi Jim,
>
> >> Is it possible to achieve TCP-like semantics for unidirectional,
> >> opaque data transfer in CORBA?
>
> Sure. There are several ways.
>
> >> Yes, I know that I could open do this on plain, old TCP sockets,
> >> but it seems to me that it should be possible to achieve something
> >> similar (albeit with a bit more overhead) using CORBA.
>
> Right.
>
> >> My read of the CORBA Messaging spec is that using a 'oneway' and
> >> the QoS SYNC_WITH_TRANSPORT policy should achieve what I am looking
> >> for (assuming IIOP): i.e. client blocks if flow controlled; client
> >> notified (though perhaps not immediately) if connection is dropped;
> >> once data is accepted by the ORB it is guarenteed to make it to the
> >> remote object reliably, sequenced, etc, assuming connection and
> >> remote object are "up". Is this right?
>
> Yes, that's correct.
Unfortunately, it's not. :-(
If you look at the Messaging 1.2 spec, it specifically says that for TCP
(IIOP), SYNC_NONE and SYNC_WITH_TRANSPORT are equivalent from a
reliability point of view. The only difference is that
SYNC_WITH_TRANSPORT waits until the transport has accepted the message
for delivery. SYNC_WITH_TRANSPORT will not guarantee that the message
has received its destination, or notify the client of failure, when
using plain ol' IIOP.
When using IIOP and the QoS that Jim specified, he needs
SYNC_WITH_SERVER. If he combines it with the using the AMI_ methods for
asynchronous calls, then he can get multiple requests on the wire
simultaneously from one thread. Doing it this way, of course, will
require sequence numbers in the messages if he needs to detect
reordering.
If he can run over a true store-and-forward transport (of which I don't
know any ORBs that provide this yet), SYNC_WITH_TRANSPORT will meet his
QoS requirements.
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Jim Robinson
Schmidt" <sch...@cs.wustl.edu> wrote:
Thanks for the responsding to my questions, Doug.
>> A second question concerns what happens if the server for a
>> persistent object goes down and then comes back up. Using TAO 5.1.2
>> I noticed that when the server goes down, the client gets TRANSIENT
>> exceptions. This is what I might expect. However, when the server
>> comes back up the exceptions disappear but the remote object does
>> not get the data.
> Are you making sure to bind stuff to the same port via the
> -ORBendpoint option?
Yes. I am consistently specifying the -ORBendpoint option. The fact that it works
SYNC_WITH_SERVER and SYNC_WITH_TARGET seems to indicate I am doing the
right thing. What I can only guess is happening is that the response that is returned
when SYNC_WITH_SERVER and SYNC_WITH_TARGET is used contains some kind
of information that the client requires to get back into a "good" state. When
SYNC_WITH_TRANSPORT is used, there is no response and thus no opportunity
to do this. Note that calling _validate_connection() will get everything
working correctly again; i.e. the remote object gets the data. Is there some kind of
rebinding that has to go on?
>> My last question concerns the behaviour of SYNC_NONE. Using TAO
>> 5.1.2 I noticed that it was possible to flow control (i.e. block)
>> the client on a oneway call. (I acheived this by suspending the
>> server) Yet, my read of the spec suggests this should never happen. Is
>> this a bug, or is my read of the spec incorrect.
>
> You're reading of the spec is "incomplete". There's nothing in the spec
> that requires an ORB not to block if it encounters flow control on the
> underlying TCP connection.
I'm looking at 98-05-05, section 5.3.2.1. Under the SYNC_NONE bullet is the following:
"The ORB returns control to the client (e.g. returns from the method invocation)
before passing the request message to the transport protocol. The client is
guaranteed not to block."
The second sentence above seems to indicate that the client cannot block, no?
BTW, is 98-05-05 the latest and greatest?
Jim Robinson
robi...@wdg.mot.com
Douglas C. Schmidt
>> Is there some kind of rebinding that has to go on?
I'm not sure if it's necessary to rebind, i.e., this might be a bug
with TAO, but if rebinding works, that's a good thing.
>> before passing the request message to the transport protocol. The client is
>> guaranteed not to block."
>>
>> The second sentence above seems to indicate that the client cannot block, no?
>>
>> BTW, is 98-05-05 the latest and greatest?
No, it's 00-02-05 I believe. Please see
http://www.cs.wustl.edu/~schmidt/CORBA-docs/00-02-05.pdf.gz
However, I think that you are correct and the SYNC_NONE policy shoud
prevent the client-ORB from blocking. Please see
http://www.cs.wustl.edu/~schmidt/RTAS00.ps.gz
for an explanation of how we achieve this in TAO.
Thanks,
Jim Robinson
OK, SYNC_WITH_TRANSPORT is a non-contender.
> When using IIOP and the QoS that Jim specified, he needs
> SYNC_WITH_SERVER. If he combines it with the using the AMI_ methods for
> asynchronous calls, then he can get multiple requests on the wire
> simultaneously from one thread.
Wouldn't the use of AMI_ methods result in multiple requests on the wire
simultaneously from one thread even without using oneways and
SYNC_WITH_SERVER? In other words, I'm afraid I don't understand what
oneways & SYNC_WITH_SERVER buys one if AMI is used. Could you please
elaborate?
> Doing it this way, of course, will require sequence numbers in the
> messages if he needs to detect reordering.
Also, how can messages get out of order when using the above? TCP (IIOP)
guarantees correct ordering over the transport. Is it possible for the
remote ORB to take the correctly ordered messages and invoke them on the
remote object in a different (incorrect) order?
> If he can run over a true store-and-forward transport (of which I don't
> know any ORBs that provide this yet), SYNC_WITH_TRANSPORT will meet his
> QoS requirements.
Even with SYNC_WITH_TRANSPORT, wouldn't it be possible for the server's
ORB to accept the message and then toss it because of, say, a temporary
resource shortage? The result being that the client sends, say, 10
messages; message 6 is dropped at the server due to aforementioned
resource shortage; but client is left unaware that anyhing bad happened
since the connection is still good and the server and remote object are
still up and running?
At any rate, what all this seems to suggest to me is that something I had
hoped would be trivial to do, achieve TCP-like sematics with respect to
reliability and asynchronicity, is not quite so trivial and in fact
requires the use of AMI. And since AMI, both callback and polling models,
require more code than synchronous calls or oneways, it seems that more
effort is required to do this than I would have expected. Is what I am
looking for not considered to be important by the CORBA community? Given
the fact that on many occasions I have seen references to people using
oneways (and thus relying on the non-portable semantics of their ORB's
implementation) to achieve something similar, I can't help but feel there
are others who would appreciate a straighforward mechanism for achieving
this. Or am I just really missing something here?
Jim Robinson
robi...@wdg.mot.com
Douglas C. Schmidt
>> Wouldn't the use of AMI_ methods result in multiple requests on the
>> wire simultaneously from one thread even without using oneways and
>> SYNC_WITH_SERVER?
Yes.
>> In other words, I'm afraid I don't understand what oneways &
>> SYNC_WITH_SERVER buys one if AMI is used. Could you please
>> elaborate?
I believe there will be less information transmitted back to the
client and the server will have less work to do to prepare a response.
>> Also, how can messages get out of order when using the above? TCP
>> (IIOP) guarantees correct ordering over the transport. Is it
>> possible for the remote ORB to take the correctly ordered messages
>> and invoke them on the remote object in a different (incorrect)
>> order?
I believe that it's an implementation detail how the ORB sends the
oneway calls. For example, the client ORB could send them on
different connections or it could spawn a thread per-call (ugh).
Likewise, the server ORB could spawn a separate thread for each
incoming oneway call, etc.
>> Even with SYNC_WITH_TRANSPORT, wouldn't it be possible for the
>> server's ORB to accept the message and then toss it because of,
>> say, a temporary resource shortage?
Yes.
>> The result being that the client sends, say, 10 messages; message 6
>> is dropped at the server due to aforementioned resource shortage;
>> but client is left unaware that anyhing bad happened since the
>> connection is still good and the server and remote object are still
>> up and running?
Yes.
>> At any rate, what all this seems to suggest to me is that something
>> I had hoped would be trivial to do, achieve TCP-like sematics with
>> respect to reliability and asynchronicity, is not quite so trivial
>> and in fact requires the use of AMI.
I think the key issue here is "portability." It's certainly the case
that ORBs could implement oneway calls precisely the way that you
want. However, the spec for one-ways allows different
implementations.
>> And since AMI, both callback and polling models, require more code
>> than synchronous calls or oneways, it seems that more effort is
>> required to do this than I would have expected. Is what I am
>> looking for not considered to be important by the CORBA community?
I think you're looking at this the wrong way. It's already possible
to use TCP/IP for TCP/IP-semantics. If you're using ACE, then this is
quite portable, so if that's what you want, use it! One-ways have a
different purpose, as do synchronous two-ways -- they aren't intended
to be "OO TCP/IP", per se!
>> Given the fact that on many occasions I have seen references to
>> people using oneways (and thus relying on the non-portable
>> semantics of their ORB's implementation) to achieve something
>> similar, I can't help but feel there are others who would
>> appreciate a straighforward mechanism for achieving this. Or am I
>> just really missing something here?
There are all sorts of ways to get TCP/IP-like behavior using CORBA,
e.g., via iterators, the A/V Streaming Service, etc.
Check out
http://www.ece.uci.edu/~schmidt/classes/ece255/content-server1.html
http://www.ece.uci.edu/~schmidt/classes/ece255/content-server2.html
http://www.ece.uci.edu/~schmidt/classes/ece255/content-server3.html
for a series of exercises that illustrate some approaches based on
iterators. We'll put the "solutions" into the next beta release of
TAO.
For more info on the A/V Streaming Service, please see
http://www.cs.wustl.edu/~schmidt/av_chapter.ps.gz
Naturally, there is an implementation of all this stuff in TAO, as
well.
Take care,