RE: Channel response serialization

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Marshall Rose
> Sent: Wednesday, July 24, 2002 6:51 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [BEEPwg] Channel response serialization
>
>
> > I'm curious about the justification for the requirement that
> responses to
> > queries on a channel be in the same order in which the queries
> were issued.
> > I understand that it has been stated that this simplifies the protocol
> > implementation. Does this mean that it simplifies the protocol or the
> > libraries that implement it? If its just the libraries, couldn't the
> > serialization requirement be made optional (i.e. part of the session
> > negotiation)?
> >
> > I ask because it seems that this excludes a large class of
> applications from
> > using BEEP, so that those of us who need truly asynchronous
> messaging are
> > left with the same problem that BEEP was intended to solve. Namely: HTTP
> > doesn't quite fit and SMTP doesn't quite fit.
>
> hi. you're right: it's probably a silly limitation in that the
> only thing that it makes "simpler" is the implementation on the
> side receiving the responses. (the side generating the responses
> couldn't care less, right?)
>
> i guess my question though is why not use the MSG/ANS approach to
> dealing with this? without understanding what the traffic looks
> like for the class of problems you're interested in, i can't
> really comment more.

The application is one where many (i.e. hundreds or thousands) of
independent entities on one peer wish to send a request to a remote peer
acting as a server. The server process the requests in parallel and sends
responses to the requests as soon as it can so that senders don't block on
the slowest response. I think this answers your question about MSG/ANS. My
reading of the RFC implies that although multiple ANS can be sent in any
order to a single MSG. The processing of multiple MSGs on one channel is
still performed serially, right?

Now I could use a pool of channels. But this seems wrong for several
reasons:

1. I would like to use channels for semantic purposes - i.e. they are
strongly associated with the meaning of the message. If I don't do that then
I have to layer another addressing mechanism on top of that provided by
BEEP. BEEP, itself, associates channels with message purpose by assigning
channel 0 as the control channel.

2. If I'm going to have a pool of channels, why not just have a pool of
sockets instead? OK, I know there are some reasons but the more that I have
to layer on top of BEEP, the less compelling is the argument for using it.

3. If I can implement parallel MSG/RPY over a single logical channel, then
BEEP could do it over a single BEEP channel and save me the bother.

>
> /mtr
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg