[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Re: [riena-dev] Riena Update

Hi Christian,

I trust that Jan's responses address your questions. Since he didn't cross-post to the Riena dev mailing list I've included his response below. One thing I would like to add...the remote services API doesn't specify/take a position WRT connectionless or not for transport...such choice(s) are left to provider impls (as with serialization/marshalling format and wire protocol).

Thanks Jan for responding.

Scott

Jan Rellermeyer's email 1/13/2009:

I looked at this http://en.wikipedia.org/wiki/Connectionless_protocol
and I see what you are getting at. True connectionless protocols are
based on UDP or IP. As soon as you have TCP/IP you have a connection.
ok.


Yes, that's usually what people mean by connectionless. But such
protocols are not well-suited for things like RPC because they don't
provide you with any delivery guarantees, which makes the failure model
extremely complicated.

HTTP 1.0 creates a connection for each request and response and throws
it away afterwards by closing it.



> So I think what I meant was a protocol that does not have a persistent
> connection. So a connection that is kept over the lifecyle of the
> service proxy and is not closed after each remote service invocation.

HTTP 1.1 allows persistent connections, thus works much like R-OSGi with the default transport (which also sets SO_KEEPALIVE) :-) Just that R-OSGi allows for better pipelining of requests and has smaller message headers.


> So R-OSGi, the generic server provider and also XMPP over a XMPP
> server, they are all holding on to a persistent connection all the
> time independant of the remote service calls you are making ?
> > right ?

AFAIK, yes. And there are effective advantages in doing so. First, you
amortize the overhead of the connection handshake over multiple calls,
which is important for the response time. At least, when you are
operating with timings from the systems world rather than the SOA world.
(I once showed that, e.g., UPnP easily has a 400 fold overhead over
R-OSGi for simple remote service calls). Second, you have a higher
chance to detect when the other side has gone down, which simplifies
your failure model. The obvious drawback is that your service provider
has to handle a dedicated connection per client, which limits the
scalability to WAN sizes rather than the Internet. But I also showed
recently that a single (desktop machine sized) service provider could
serve about 550 simultaneous concurrent clients all continuously
invoking services with R-OSGi. And that scale was by no means bounded by
the number of connections to keep open but obviously by the other system
resources.


Cheers,

Jan.
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Christian Campo wrote:
Scott,

I looked at this http://en.wikipedia.org/wiki/Connectionless_protocol and I see what you are getting at. True connectionless protocols are based on UDP or IP. As soon as you have TCP/IP you have a connection. ok.

So I think what I meant was a protocol that does not have a persistent connection. So a connection that is kept over the lifecyle of the service proxy and is not closed after each remote service invocation.

So R-OSGi, the generic server provider and also XMPP over a XMPP server, they are all holding on to a persistent connection all the time independant of the remote service calls you are making ?

right ?

christian

Am 13.01.2009 um 18:13 schrieb Scott Lewis:

Hi Christian,

Christian Campo wrote:
Hi Jan,

thanks. So that would mean you have a connected socket between the
various spaces all the time. So the point from the discussion with
Scott that I think that this make R-OSGi a connectionoriented provider
and not a connectionless provider. I am not saying this is good or bad
here.

Like with Webservices (say SOAP or any other protocol) over HTTP its
possible to reuse a connected socket but typically you disconnect
after each call and connect for the next one.

Is that the correct assumption Jan ?

So that makes me still wonder if there is an ECF provider currently
available that is connectionless ?

By this definition of connectionless, not currently. So perhaps Riena can/will/should be the first?

Scott

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________ riena-dev mailing list riena-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/riena-dev