Re: Asynchronous BEEP draft status

Hello Martin,

I have a couple of responses to your message, as well as some comments  
on the draft.

===

>> c - BEEP adoption suffers from non-interoperability of existing  
>> toolkits.
>
> Feature negotiation ensures that this option cannot be used without  
> agreement.  I can't see how this work affects interoperability.

If I create a profile that requires the use of a new feature, then  
that profile can not be implemented on a BEEP stack that does not  
provide that feature, so that profile cannot interoperate with that  
BEEP stack.  Perhaps this isn't the classic definition of  
interoperability, but it is something to consider.

However, upon further consideration, I do not see how a profile could  
actually _require_ the use of the async feature, so the  
interoperability argument is moot.

>> The way Xgrid uses BEEP is to send an immediate empty RPY for each  
>> MSG
>> that is received.
>
> This is a valid choice for your application.  This solution doesn't  
> presume to prevent this sort of behaviour, only expand the choices  
> available to application protocol designers.

My point is that the protocol may already be flexible enough to solve  
the problem without inventing new features.  I do not think expanding  
choices for the sake of choices is a good idea.  If there is already a  
good way of doing something, we shouldn't add an additional way.

> (Note that empty RPYs are a redundant receipt indication; you get  
> receipt indications at the TCP layer as well.)

I do not think the TCP layer can indicate that that the remote  
application has read all of the message's frames from the socket, can  
it?  That is what the empty RPY indicates, right?

===

Anyways, reading through the draft, I think one reason I am resistant  
to this feature is that I do not fully understand when it would better  
than the alternatives.  As I see it, the two main alternatives to  
async channels are empty replies and multiple channels.


The consequence of empty replies is that is pushes the burden of  
message correlation onto the application layer.  I can appreciate that  
this is undesireable for applications that don't already have a reason  
to correlate messages.  But this could be hidden from the application  
at the toolkit level.  Rather than inventing a new type of channel, we  
could define some standard MIME headers that applications that require  
async messaging should use.  And toolkits could add features to  
automatically add these headers and correlate replies with messages  
using them.  Toolkits that didn't provide these features automatically  
could still interoperate with those that did, as long as the profile  
implementor handled the message correlation manually.

The other option is multiple channels.  Sending messages on separate  
channels has the asynchronous behavior you want, right?  By using one  
channel per message you can implement your profile on any BEEP stack.   
The client can control the amount of parallel requests it makes by  
limiting the number of channels it opens, and the server can control  
the amount of parallel requests it has to handle by limiting the  
number of channels it allows the client to open.  Again, the toolkit  
could provide features to automatically open and close channels for  
each message that is sent, or keep channel pools open, so the  
application still wouldn't have to deal with these details.

In fact, the one-channel-per-message strategy provides even greater  
asynchrony than async channels, because the frames of both the MSGs  
and the RPYs on independent channels can be interleaved over the  
socket.  The async channels feature specifically excludes this: "An  
asynchronous channel must still observe the rules in [RFC3080]  
regarding segmented messages. Each message must be completed before  
any other message can be sent on that same channel."

However, I am concerned about this statement: "Different "ANS"  
messages that are sent in a one-to-many exchange may be interleaved  
with responses to other "MSG" messages."  This seems to be a bad  
idea... is this saying that ANS and RPY frames can be interleaved on  
async channels?  Why?

I am especially concerned about the note following that statement: "It  
is recommended that BEEP peers do not generate interleaved ANS  
segments."  Why is it recommended that you do not interleave ANS  
segments?  Isn't this a basic feature of BEEP?  Is this statement mean  
only in the context of async channels, or all channels?


Based on this analysis it looks like async channels provide a  
compromise between empty RPYs, which puts the burden of message  
correlation onto the application, and multiple channels, which puts  
the burden of channel management onto the application.  Both of the  
burdens could be lessened by toolkits or frameworks, without changing  
the BEEP wire protocol.  But if you just want your server to be able  
to answer out of order, but you don't want to correlate the replies  
yourself, and you don't want the answers interleaved, then I see how  
the async channel is the most efficient solution.

-David