Re: [ecf-dev] Re: [riena-dev] Riena Update

[Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>]

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