Blocks Extensible Exchange Protocol (beep)

Francis Brosnan Blazquez | 19 Nov 2008 10:03

[Vortex] [ANN] Vortex Library 1.0.16 '10.000 Days' release is ready!

###################################################
      ##              Vortex Library 1.0.16            ##
      ##              "10.000 Days release"            ##
      ###################################################

Release note
~~~~~~~~~~~~

  Advanced Software Production Line is proud to announce the Vortex
  Library 1.0.16 "10.000 Days" release availability: an open source
  "BEEP Core" protocol implementation written in C, mapped onto
  TCP/IP.

  Vortex Library has been developed inside the Af-Arch project as its
  data transport layer.

  Vortex Library is a stable and robust application protocol
  development toolkit. Currently it is running under Microsoft Windows
  and GNU/Linux platforms.

  Check out the following links to get ready with Vortex Library:

    - http://www.aspl.es/vortex
      [Vortex Library homepage]

    - http://www.sf.net/projects/vortexlibrary
      [Sources and Win32 binaries]

    - http://fact.aspl.es
      [Af-Arch homepage where Vortex Library is being developed]

(Continue reading)

headers

Martin Thomson | 26 Nov 2008 00:58

Asynchronous BEEP draft status

Hi all,

At the 73rd IETF meeting in Minneapolis, I talked to Lars Eggert, who
has agreed to sponsor my asynchronous channels draft.  This means
that, pending review, this document will be published as a standards
track RFC.

  <http://tools.ietf.org/html/draft-thomson-beep-async>

If you have any feedback on this document, I'd appreciate it if you
could send that feedback to this list, or to me directly.

Regards,
Martin

headers

Francis Brosnan Blazquez | 26 Nov 2008 09:48

Re: Asynchronous BEEP draft status

Hi Martin,

The draft looks good to me. Really interesting work. Congratulations!

--

-- 
Francis Brosnan Blazquez <francis <at> aspl.es>
Advanced Software Production Line, S.L.

headers

Marshall Rose | 26 Nov 2008 16:51

Re: Asynchronous BEEP draft status

+1

On Nov 26, 2008, at 00:48 , Francis Brosnan Blazquez wrote:

> Hi Martin,
>
> The draft looks good to me. Really interesting work. Congratulations!
>
> -- 
> Francis Brosnan Blazquez <francis <at> aspl.es>
> Advanced Software Production Line, S.L.
>

headers

Sam Roberts | 26 Nov 2008 19:17

Re: Asynchronous BEEP draft status

-1

I am unconvinced of the value of this draft, for three reasons:

a - This draft describes how to build into BEEP something you can
already do with BEEP (several ways).

I can write a trivial example using vortex that implements the
motivating use-case for those unconvinced.

b - BEEP adoption suffers from perceived complexity.

I don't personally think it is more complex than it has to be, but it
would be better to document how to use what it offers than to extend
it.

c - BEEP adoption suffers from non-interoperability of existing toolkits.

If implementors are already not writing interoperable toolkits when
implementing the existing RFC3080/3081, optional extensions are going
to make this situation worse.

Cheers,
Sam

headers

Sam Roberts | 26 Nov 2008 20:11

Re: Asynchronous BEEP draft status

On Wed, Nov 26, 2008 at 10:17 AM, Sam Roberts <vieuxtech <at> gmail.com> wrote:
> a - This draft describes how to build into BEEP something you can
> already do with BEEP (several ways).
>
> I can write a trivial example using vortex that implements the
> motivating use-case for those unconvinced.

Sorry. Couldn't resist implementing this.

Draft states following use case:

"""
   Asynchronous applications require a protocol that is able to support
   a large number of concurrent outstanding requests.  The analogy of a
   channel as a thread does not scale to the large number of threads
   used in modern systems.  Modern applications regularly have large
   numbers of concurrent processing threads.  Thus, a better way of
   multiplexing large numbers of concurrent requests is required.

   This document describes an BEEP feature, an extension to BEEP, that
   enables the creation of an asynchronous channel.  An asynchronous
   channel is a channel where response ordering is not fixed to the
   order of the requests sent by the client peer.  An asynchronous
   channel is identical to other channels, using unmodified framing;
   only requests may be processed in parallel and responses may be sent
   in any order.
"""

Note that Vortex delivers each MSG on a seperate thread, exactly as
described above.

(Continue reading)

headers

David Kramer | 26 Nov 2008 20:40

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>

(Continue reading)

headers

Thomson, Martin | 27 Nov 2008 00:21

RE: Asynchronous BEEP draft status

Hi Sam, David,

I'm sorry that you think that this is unnecessary. I acknowledge the fact that profiles are able to define
and use other means of request-response correlation. The intent of this work is to save application
protocols and clients from the additional complexity of managing disparate solutions to the problem.

As an intermediate layer, one of the goals of BEEP is to simplify the development of an application
protocol. All the workarounds that I've seen have only pushed more complexity on the application protocol.

One other advantage of this work is that the method for addressing asynchrony becomes unified. There
aren't multiple fragmented solutions, some using headers, others using protocol-specific parameters.

A point that I'd like to stress is that this is entirely optional. Firstly, both peers must support (and
indicate willingness to use) the feature. Secondly, both peers must agree to use the mode before a channel
can be created with the feature enabled. From this perspective, I cannot see why you are so resistant to
this idea.

Sam:
> Note that Vortex delivers each MSG on a seperate thread, exactly as
> described above.

If this is the case, then this is directly against the stated requirement in RFC 3080, 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.

It is possible, at the application to ignore this requirement if you so choose. That is entirely your
prerogative, and as long the semantics of your profile are explicit, then this wont have any negative consequences.

Of course, to operate in this mode, a client will have to implement a demux layer that redirects responses to

(Continue reading)

headers

David Kramer | 27 Nov 2008 03:24

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.

(Continue reading)

headers

Sam Roberts | 27 Nov 2008 03:44

Re: Asynchronous BEEP draft status

On Wed, Nov 26, 2008 at 3:21 PM, Thomson, Martin
<Martin.Thomson <at> andrew.com> wrote:
> Sam:
>> Note that Vortex delivers each MSG on a seperate thread, exactly as
>> described above.
>
> If this is the case, then this is directly against the stated requirement in RFC 3080, 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.

This is far-fetched.

Vortex is acting correctly. It delivers the MSGs to the API serially
(to different threads).

BEEP places no requirements on the what "process" means for a profile.

[reordered]
> Sam:
>> BEEP msgnos are ordered across a channel, of course, but application
>> msgs can be replied whenever you want.
>
> This is in direct contravention of the quoted requirement, above.

BEEP RPYs are passing over the wire in the RFC defined order.

I could write the code in the other toolkits I use, too (beepy,
swirl/beepcore-c, and beep4j).

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

2	September 2012
1	August 2012
1	July 2012
1	May 2012
3	January 2012
2	October 2011
2	August 2011
1	July 2011
2	June 2011
1	May 2011
1	March 2011
1	January 2011
1	December 2010
1	October 2010
1	September 2010
1	May 2010
1	April 2010
1	March 2010
1	September 2009
1	June 2009
1	April 2009
12	March 2009
1	February 2009
4	January 2009
24	November 2008
2	October 2008
1	September 2008
2	July 2008
5	May 2008
2	April 2008
1	February 2008
1	December 2007
7	November 2007
1	October 2007
1	September 2007
2	August 2007
4	July 2007
1	June 2007
1	May 2007
1	April 2007
1	March 2007
2	February 2007
2	December 2006
1	November 2006
4	September 2006
2	August 2006
3	July 2006
1	June 2006
4	May 2006
8	April 2006
4	March 2006
13	February 2006
15	January 2006
3	December 2005
1	November 2005
2	October 2005
1	January 2005
12	August 2004
2	June 2004
10	May 2004
6	March 2004
8	February 2004
3	January 2004
1	November 2003
4	October 2003
15	September 2003
6	July 2003
10	June 2003
5	May 2003
3	March 2003
2	February 2003
1	January 2003
6	December 2002
3	October 2002
16	September 2002
35	August 2002
29	July 2002
27	June 2002
2	May 2002
5	April 2002