Re: [beep4j-user] Concurrency issues

[Simon <co...@gm...>]

On May 7, 2008, at 7:02 AM, Thomson, Martin wrote:

> Now that my misconceptions about BEEP have been laid to rest, I'm
> wondering if anyone has ever considered alternative approaches to the
> message throughput problem caused by the serial nature of channels.
>
> Looking at RFC 3080, it is now clearly evident that the message number
> parameter is almost completely redundant.  Seqno is sufficient as a
> sanity check on message ordering and if messages are responded to
> sequentially, the channel identifier provides enough information to
> correlate request and response.  The only exception appears to be for
> ANS messages [1].

At least from a debugging / tracing point of view the message number  
parameter makes a lot of sense. And it allows to detect protocol  
violations, such as when a peer is not sending the replies in the  
correct order.

>
> 	
> There is no protocol reason for preventing out of order messages.  I  
> can
> also prove that with a small change, beep4j accepts out of order
> messages with no adverse effects.  The only reason this is not done is
> that the RFC says "thou shalt not".  Unfortunately, this seems to just
> be an arbitrary decision; the reasoning has not been retained for our
> benefit.  I'd be interested in learning of any sound, technical reason
> why the protocol must operate in this fashion (as opposed to reasons  
> why
> it isn't so big a limitation, I've heard those already).

> The idea I'm currently entertaining is to provide an initial tuning
> profile for BEEP that enables the out-of-order responses, using the
> message number as a true means of correlating request and response  
> [2].
> If this profile were accepted, subsequent continuous channels would be
> able to send responses as they are processed without regard for
> ordering.  Unfortunately, this would affect all channels in the  
> session
> and could prevent channels from co-existing, assuming that certain
> applications or channel profiles require this serial behaviour (e.g.
> DELETE then PUT example from the previous mail [3]).  Of course, peers
> that provide purely serial profiles wouldn't have to offer or accept  
> the
> profile.
>

I propose that you send those concerns / questions to the beep  
community list (see http://beepcore.org/support.html).

> I'm interested in how you would see a tuning profile working with
> beep4j.

I've never thought about how to implement tuning profiles because I've  
simply never had a use for the existing tuning profiles. Additionally,  
as you have guessed, a tuning profile requires quite a bit of access  
to the session internals, which at that point in the lifetime of  
beep4j I do not feel comfortable to provide.

>
>
> My thought is that tuning profiles [4] are best implemented within
> beep4j; they need access to certain internals that aren't really
> appropriate for the public API.  My initial thoughts were that the
> profile would be offered at the discretion of the user (i.e. by
> registering the profile URI in SessionHandler.connectionEstablished).
> beep4j would handle the details internally.  When channel open is
> requested, the profile URI could be compared to the set of supported
> (and offered) profiles.  Channel handlers for the tuning profile would
> have access to the extended interface for the session  
> (InternalSession)
> which could be extended with those additional features necessary for
> dealing with the profile.  (e.g. setSynchronous(boolean) or  
> startTLS())
>
> Cheers,
> Martin
>
>
> [1] I can't see how interleaving split ANS frames could ever be a good
> idea, or why it deserves this special exemption from the rule, but  
> it's
> there in black and white.
>
> [2] Yes, I'm fully capable of working within the limitations, but  
> that's
> sub-optimal and I find the limitation irritating enough to do  
> something
> about it.
>
> [3] That example is actually misleading.  BEEP doesn't mandate an  
> order
> to processing; therefore, the only way to guarantee the order of
> execution is to wait for a response to the first request.
>
> [4] I've also looked at the TLS filter example in Mina and it looks
> relatively easy to implement.  Basic support for the TLS profile would
> be another interesting project.
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> beep4j-user mailing list
> bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beep4j-user