|RE: [ecf-dev] Re: [riena-dev] Riena Update|
> 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.
Back to the top