Multiple callbacks

[Jonathan]

Hi All,

no replies but I keep posting... who knows, maybe they're all on
holiday. ;-)

What's the intended behavior when receiving multiple informational
callback BERPs? The specs does not say anything about it, is it
allowed? If not, what should the server do? If yes, should all
callbacks be called or only the last one?

On the same line, how should the server react when receiving invalid
informational BERPs? Should it send back a Server Error (which code)
or ignore the packet?

Many questions, I know, but the specs lacks some stuff about the
handling of a non compliant client/server.

Regards,
Jonathan

[Jared "Lucky" Kuolt]

I suspect that the spec was designed to have one callback per request.
Any more than that might complicate how things are handled. However,
since the spec is fuzzy in this regard I'm sure you can get away with
implementing multiple callbacks. I think the only sane way to handle
it is to perform each callback in the sequence given. (I would love
for TPW to comment on this).

Regarding the invalid info berp, I would expect the server to fail
because if part of the request is invalid, so is the whole request.

To answer your previous question regarding connection-per-request: I
think it's smarter to have persistent connections, which I implemented
in my Ruby bertclient library[1].

[1]: http://github.com/luckythetourist/bertclient

--
Lucky ♣ http://luckythetourist.com

[Jonathan Stoppani]

Hi Lucky,

thanks for your reply!

On Aug 16, 2010, at 8:51 PM, Jared Lucky Kuolt wrote:

I suspect that the spec was designed to have one callback per request.

Probably you're right.

Any more than that might complicate how things are handled. However,
since the spec is fuzzy in this regard I'm sure you can get away with
implementing multiple callbacks. I think the only sane way to handle
it is to perform each callback in the sequence given. (I would love
for TPW to comment on this).

This is how I already handle requests of this kind, and is also quite
easy to implement.

Regarding the invalid info berp, I would expect the server to fail
because if part of the request is invalid, so is the whole request.

But there too, the spec does not define any specific error codes, at
least an "Invalid request" should be added IMHO.

To answer your previous question regarding connection-per-request: I
think it's smarter to have persistent connections, which I implemented
in my Ruby bertclient library[1].

And how do you handle a request that arrives before the response to the
previous one is sent back?
Maybe this can seem obvious in a blocking environment, but I'm using
an async library to write the client and server implementations, so I
expect that a client can send a second request without waiting for the
response to the first one. How should the server handle in this case?
Should it enqueue the second request until it has sent the response to
the first one?

Thank you again for your insights, unfortunately the spec is not very
clear for some points, mainly in regard to the handling of invalid
requests.

Cheers,
Jonathan

[Jared "Lucky" Kuolt]

On Wed, Aug 25, 2010 at 7:05 PM, Jonathan Stoppani
<st.jo...@gmail.com> wrote:
> But there too, the spec does not define any specific error codes, at
> least an "Invalid request" should be added IMHO.

The best we can do for now is to properly create an {error, ...} return berp.

> And how do you handle a request that arrives before the response to the
> previous one is sent back?

Pretty much like anything else, for any synchronous request you must
wait for a response before sending another request.

> Maybe this can seem obvious in a blocking environment, but I'm using
> an async library to write the client and server implementations, so I
> expect that a client can send a second request without waiting for the
> response to the first one. How should the server handle in this case?
> Should it enqueue the second request until it has sent the response to
> the first one?

I think the request/response model is the only valid way of handling
this sort of thing. If you need a second request to be performed while
waiting for the first, you should have a separate connection. The
protocol is simply not aware of any complex message state.

This also appears to be a reason why the asynchronous ``cast`` was
created, so you wouldn't tie up a single connection if you didn't need
the return value right away. In this way, the protocol is very
obviously inspired by Erlang's message passing.

>
> Thank you again for your insights, unfortunately the spec is not very
> clear for some points, mainly in regard to the handling of invalid
> requests.

Without a protocol-defined set of error codes/responses, we can only
do our best per implementation. I'm certainly willing to collaborate
to create a community standard.

>
> Cheers,