[
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