Subject: [BEEPwg] Query related with message ordering on a channel.

From: Alok Gupta <[email-masked]>
Date: Sat, 01 Dec 2001 01:16:39 +0530

Hi,

I have a query related with the ordering of the replies on a channel in
a BEEP session.

The RFC 3080 says that on a channel, the messages MUST be processed in
the same order as they were received and then the replies to those
messages MUST be generated in the same order. My question is that the
processing time for all the  message will not be same so why hold the
replies for the messages which have been processed before the reply is
ready for the previously received messages.

Please refer to the  RFC 3080 in the following sections:
Section 2.6.1

     "...........A BEEP peer acting in the server role must process
     all "MSG" messages for a given channel in the same order as
     they are received.  As a consequence, the BEEP peer must
     generate replies in the same order as the corresponding "MSG"
     messages are received on a given channel......... "

Section 2.6.1

     "............A BEEP peer acting in the server role may process
     "MSG" messages received on different channels in any order it
     chooses.  As a consequence, although the replies for a given
     channel appear to be generated in the same order in which the
     corresponding "MSG" messages are received, there is no
     ordering constraint for replies on different
     channels..........."

Either I have not followed the point properly or this is an unnecessary
requirement from the BEEP protocol.

Could anybody explain this?

Thanks,
Alok Gupta.

---

From: Greg Hudson <[email-masked]>
Date: 30 Nov 2001 10:02:50 -0500

> ready for the previously received messages.

It simplifies the implementation of some application protocols if you
can assume that replies will be received in the order that requests are
sent.  That is why BEEP requires that replies be synchronous within a
channel.  If you have some unrelated requests and want to be able to
receive replies for them in any order, send them on different channels.

(And yes, this means BEEP isn't necessarily a good fit for a protocol
where all requests are independent of each other and where it's
important not to let one slow request hold up feedback on any other
request.  For such a protocol, you'd have to manage a pool of channels
and create a new one each time you have a request to send and no free
channel in the pool; that's a lot of bookkeeping.)

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Darren New <[email-masked]>
Date: Fri, 30 Nov 2001 07:49:01 -0800

Greg Hudson wrote:
> sent.  

Also, the profile should behave as if each request is processed in full
before the next one is examined. I.e., a request to search a database
followed by one to delete records in that database should not delete
anything before the search is complete. Of course, if you have
independent operations, it's possible to implement such things in a more
efficient way, but that's the intent.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: "Huston" <[email-masked]>
Date: Fri, 30 Nov 2001 10:08:09 -0700

> channel in the pool; that's a lot of bookkeeping.)

Greg is right but it can be made to work without too much pain.
beepcore-java has a facility (ChannelPool and SharedChannel) to do channel
pooling for you, they were designed for just such a purpose. If you are not
using beepcore-java it can at least serve as an example.

--Huston