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

["Rellermeyer Jan Simon" <rellermeyer@xxxxxxxxxxx>]

> 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.