headers
Thomson, Martin | 16 May 2008 08:59

Asynchrony and BEEP

Hi All,

Since the IETF WG wrapped up, this list seems to be fairly quiet, but I
have a technical matter I'd like to discuss.

I have an asynchronous application that needs a protocol.  Similar to
the experience of RFC 3117, I did a little research on protocols in the
hopes of finding one that fits (more or less).

Until recently, I was confident that BEEP provided all that I needed.
It turns out a fundamental assumption I had made was quite wrong
(there's a lesson in that).  I had assumed that the presence of a
message number that must be unique would mean that responses to messages
were correlated based on this number.  Someone recently pointed out
Section 2.6 of RFC 3080 that disabused me of this notion - channels are
entirely serial in each direction.

Having read more material on the subject, I'd like to describe the
problem that this presents.  I'd also like to discuss a possible
solution.

The application in question (location services) requires that any
protocol it uses scales well.  Our estimates predict a wide range of
usage rates, but at the upper end the rate could be something in the
order of 100s of requests per second.  However, throughput is not the
only concern.  Requests take varying amounts of time to be processed;
current estimates are anything from milliseconds to somewhere between 10
and 20 seconds.

Case study: an unnamed protocol [1] from the same field that uses an
(Continue reading)

Permalink | Reply | 4 comments |
headers
Francis Brosnan Blazquez | 19 May 2008 15:41
Picon

Re: Asynchrony and BEEP

Hi Martin,

Assuming the set of details you provided, I think you are facing a
problem which is simple to solve using features already provided by
BEEP. Here is how:

- Create two channels, one to push jobs and one to receive jobs
finished. 

- The channel to push jobs use a MSG/RPY pattern. Once the listener
receive a job request (MSG), it is queued/handled as desired, but before
doing that, a RPY must be sent to acknowledge MSG reception.

- The channel that receive jobs finished issue an initial MSG to open
the possibility to receive ANS replies that carries jobs finished. Now,
each time the listener have a job finished he send it back as an ANS
reply to the MSG received on this channel. This will allow to send in
any order jobs as quickly as they are finished.

Now, I would like to comment some assertions you have done:

1) (Please see 3.4 and 4.1 of [1]) The technical reason to make
intra-channel processing to be serial is because it is the most widely
available request/response model in use today. Thus, it is required to
be represented in BEEP, mainly because people use it. You say it is used
in some cases (????) but it is by far the most popular model used in
connection oriented escenarios (like HTTP). 

However, what makes BEEP different, is that channel pipeline is *not*
the only one invocation model. You can use several channels or use
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomson, Martin | 21 May 2008 08:09

RE: Asynchrony and BEEP

Hi Francis,

Thanks for the response.

I am taking an existing protocol and binding it to BEEP.  Using two
separate channels in the fashion you describe is only possible if I
wanted to (or was able to) change the protocol payload.  Currently, the
protocol is bound to HTTP.  The idea was to move to BEEP to allow for
increased throughput.  However, the method you suggest requires that
request/response correlation is performed at a higher layer than BEEP.
This either requires modification of the application protocol, or
insertion of another protocol layer.  This is either infeasible or
unpalatable.

As far as your comments go, I had a little trouble correlating each
comment with my original statements.  Apologies if I've misinterpreted
anything you've said.  I'll reply inline below.

Francis Brosnan Blazquez:
>
> Now, I would like to comment some assertions you have done:
> 
> 1) (Please see 3.4 and 4.1 of [1]) The technical reason to make
> intra-channel processing to be serial is because it is the most widely
> available request/response model in use today. Thus, it is required to
> be represented in BEEP, mainly because people use it. You say it is
> used
> in some cases (????) but it is by far the most popular model used in
> connection oriented escenarios (like HTTP).
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Francis Brosnan Blazquez | 21 May 2008 23:47
Picon

RE: Asynchrony and BEEP

> Hi Francis,

Hi Martin,

> Thanks for the response.
> 
> I am taking an existing protocol and binding it to BEEP.  Using two
> separate channels in the fashion you describe is only possible if I
> wanted to (or was able to) change the protocol payload.  Currently,
> the
> protocol is bound to HTTP.  The idea was to move to BEEP to allow for
> increased throughput.  However, the method you suggest requires that
> request/response correlation is performed at a higher layer than BEEP.
> This either requires modification of the application protocol, or
> insertion of another protocol layer.  This is either infeasible or
> unpalatable.

Certainly. Maybe you can use a MIME header to flag the payload with a
transaction number.

> As far as your comments go, I had a little trouble correlating each
> comment with my original statements.  Apologies if I've misinterpreted
> anything you've said.  I'll reply inline below.

Ok.

> Francis Brosnan Blazquez:
> >
> > Now, I would like to comment some assertions you have done:
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomson, Martin | 22 May 2008 02:42

RE: Asynchrony and BEEP

More inline,

> 
> Ok. Looking at the request/response model as a natural evolution from
> the local function invocation, it is clear that order matter.
> 
> You invoke the function/service looking for some result/resource,
> which,
> with great probabilities will be used for next invocations, or to stop
> current flow if an error occur. That's why you need the serial nature
> (and the reason why it is widely present in other protocols).
> 
> More than a technical reason, I see an implementation issue. Most of
> languages used to write networked applications do it by invoking
> functions in order and according to the results they perform.

Debating the advantages of serial processing, while entertaining, isn't
relevant to the discussion.  I am putting forward a different use case.

I'm not attempting to invalidate serial processing; far from that.  I am
only pointing out that it isn't always the best approach.

> Now, moving the focus to the other side. Assuming an our of order
> scenario, this will require the caller to push its request into
> something like a pool of pending request, and to poll frequently if
the
> request was satisfied. I don't know how do you see this, but I found
> quite complex and unnatural to make it as the default behaviour, not
> only in BEEP, but in any connection oriented protocol.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane