Re: Asynchronous BEEP draft status

On Nov 26, 2008, at 11:11 AM, Sam Roberts wrote:

> BEEP msgnos are ordered across a channel, of course, but application
> msgs can be replied whenever you want. The profile designer specifies
> the content and meaning of beep message payload.
>
> Profile designers are not required to map BEEP internal msgno 1-to-1
> to their profile's message identifiers. Often, this is convenient.
> When it is not convenient, don't do it.

I can provide some additional real-world evidence to back up Sam's  
claims.

The way Xgrid uses BEEP is to send an immediate empty RPY for each MSG  
that is received.  The RPY in this case acts as nothing more than an  
acknowledgement that the MSG was received.  In Xgrid, all messages,  
whether they are requests, responses, or notifications, are mapped to  
BEEP MSGs.  When Xgrid wants to reply to a request, it just sends it  
in another MSG.  The body of the MSGs indicate whether the message is  
a request or a response, and each request includes a correlation ID  
which is then also included in the corresponding response.

The bodies of requests Xgrid sends look something like this pseudo-xml:

<message>
   <message-type>request</message-type>
   <message-name>status</message-name>
   <message-correlation-id>87</message-correlation-id>
   <message-body>...</message-body>
</message>

It turns out that Xgrid actually responds to all messages in order, so  
this technique isn't being used to allow for out-of-order responses,  
even though it could be.  In Xgrid's case, this technique is being  
used to allow for notifications -- messages for which there is no  
response.  The use of the ANS-style replies is not suitable for Xgrid  
because of the requirement that each ANS message have a unique ID,  
which results in both the sender and receiver having to keep track of  
every outstanding ANS ID.  For long-running connections with millions  
of notifications this puts pressure on memory and reduces performance.

So I have to agree with Sam that on the face of things this proposal  
for a new asynchronous channel type seems unnecessary.  Applications  
do not need to use BEEP message-numbers, they can ignore that detail  
of the BEEP implementation and just implement their own message  
tracking through the message headers or bodies.

However, while we're on the topic of improving the BEEP protocol, if  
it were up to me the one change I would consider making is to add a  
new message type, the notification (NFN).  This would be like a MSG,  
except that the peer does not send a RPY.  This might be a simpler  
change that achieves the OPs goals.  However, it really isn't very  
important, because it is easy to send empty RPYs, and the advantage of  
sending empty RPYs is that they act like an acknowledgement of  
receipt.  If you were using NFN style notification messages the only  
acknowledgement you would get would be an eventual SEQ frame.

-David