Keep alive connections

[Samuel Stauffer]

It seems that currently ernie closes the connection after serving an
RPC request, and looking at the ruby BERT-RPC library it seems it does
the same. Is this behavior part of the spec or an implementation
issue? For my use-case I would have a good number of RPC calls per web
request, and being able to service multiple calls over a single
connection would certainly be more efficient.

If it's an implementation issue then I can modify ernie for my uses,
but if it's a spec issue I worry that it'll be too restricting.

Thanks,
Samuel

[Tom Preston-Werner]

On Oct 22, 12:16 am, Samuel Stauffer <sam...@lefora.com> wrote:
> It seems that currently ernie closes the connection after serving an
> RPC request, and looking at the ruby BERT-RPC library it seems it does
> the same. Is this behavior part of the spec or an implementation
> issue? For my use-case I would have a good number of RPC calls per web
> request, and being able to service multiple calls over a single
> connection would certainly be more efficient.

I originally had something in the spec about persistent connections,
but I removed it since I wanted BERT-RPC to be as transport-agnostic
as possible. But I agree that persistent connection are important.
Ideally BERT-RPC clients and servers would automatically detect
connection closes from either end and handle them properly. For
example, a smart client would detect if the server left the connection
open after the final BERTP or stream 0-header and attempt to send the
next request on the same connection. In this manner, both persistent
and single-connection clients and servers could live together
harmoniously. A simple timeout on the server side would be wise to
prevent socket starvation, but otherwise I don't see any problems.
What are your thoughts on that approach?

Tom

[Kenji Rikitake]

I'm thinking about using BERT-RPC over an encrypted connection
(namely SSH or SSL/TLS) to an Erlang node. In such a case,
the persistent connection capability is critical, because setting up
the cryptographic association for every RPC attempt is time-consuming.

I'd be glad if a persistent connection handling scheme is formally
described in a later version of BERT-RPC specification.
Time-out based disconnection is a solution, but allowing an explicit
disconnection from the client side will do no harm on the server side
and I think it's worth considering.

BTW I appreciate the specification goes public; it's a good framework
for people thinking about implementing RPC protocols with Erlang.

Kenji Rikitake

[Samuel Stauffer]

Sounds like a good idea. That's pretty much what I did in the Python client. Before starting a new transaction it does a select to check if the connection is still alive.