JERI Multiplexing protocol increasing the number of sessions.

[Peter Firmstone <pe...@zeus.net.au>]

Hello,

The JERI multiplexing protocol allows 128 sessions between two nodes, 
when this value is exceeded, an exception is thrown and a connection 
cannot be made.

I have run into some situations during stress testing where 128 sessions 
isn't enough.

The JERI multiplexing protocol sends a signed byte, the allowable range 
is from 0 to 127 (inclusive) and consumes it at the remote end.

However I have noticed in the implementation, checks for maximum and 
minimum sessions occurs while the number is a 32 bit integer, before 
being cast to byte, so basically we can change this to an unsigned byte, 
without breaking compatibility with existing implementations (until we 
exceed 128 sessions).

Using an unsigned byte would allow a maximum 255 Sessions.

As both endpoints have to consume a byte, increasing this value further 
would break the protocol.

Existing connections break when the number of sessions exceeds 128, this 
will not cause any unexpcected additional breakage.

I'm not aware of any additional third party implementations of the JERI 
protocol.

It's also worth noting that the JERI implementation of today, is much 
faster and more efficient than JERI released in Jini 2.1, 128 
connections would have suffereed from contention, today, this isn't an 
issue.

Regards,

Peter.

Re: JERI Multiplexing protocol increasing the number of sessions.

[Peter Firmstone <pe...@zeus.net.au>]

Thanks Gregg,

It works well in testing and allows a maximum of 256 remote object 
between two nodes over a JERI endpoint.

Is anyone approaching 128 remote object in deployment?

If no one objects in the next week, I'll assume lazy concensus.

Regards,

Peter.


On 3/09/2019 1:31 AM, Gregg Wonderly wrote:
> I think considering an unsigned byte value should be a reasonable step.
>
> Gregg
>
> Sent from my iPhone
>
>> On Sep 1, 2019, at 9:41 PM, Peter Firmstone<pe...@zeus.net.au>  wrote:
>>
>> Hello,
>>
>> The JERI multiplexing protocol allows 128 sessions between two nodes, when this value is exceeded, an exception is thrown and a connection cannot be made.
>>
>> I have run into some situations during stress testing where 128 sessions isn't enough.
>>
>> The JERI multiplexing protocol sends a signed byte, the allowable range is from 0 to 127 (inclusive) and consumes it at the remote end.
>>
>> However I have noticed in the implementation, checks for maximum and minimum sessions occurs while the number is a 32 bit integer, before being cast to byte, so basically we can change this to an unsigned byte, without breaking compatibility with existing implementations (until we exceed 128 sessions).
>>
>> Using an unsigned byte would allow a maximum 255 Sessions.
>>
>> As both endpoints have to consume a byte, increasing this value further would break the protocol.
>>
>> Existing connections break when the number of sessions exceeds 128, this will not cause any unexpcected additional breakage.
>>
>> I'm not aware of any additional third party implementations of the JERI protocol.
>>
>> It's also worth noting that the JERI implementation of today, is much faster and more efficient than JERI released in Jini 2.1, 128 connections would have suffereed from contention, today, this isn't an issue.
>>
>> Regards,
>>
>> Peter.

Re: JERI Multiplexing protocol increasing the number of sessions.

[Gregg Wonderly <gr...@wonderly.org>]

I think considering an unsigned byte value should be a reasonable step.

Gregg

Sent from my iPhone

> On Sep 1, 2019, at 9:41 PM, Peter Firmstone <pe...@zeus.net.au> wrote:
> 
> Hello,
> 
> The JERI multiplexing protocol allows 128 sessions between two nodes, when this value is exceeded, an exception is thrown and a connection cannot be made.
> 
> I have run into some situations during stress testing where 128 sessions isn't enough.
> 
> The JERI multiplexing protocol sends a signed byte, the allowable range is from 0 to 127 (inclusive) and consumes it at the remote end.
> 
> However I have noticed in the implementation, checks for maximum and minimum sessions occurs while the number is a 32 bit integer, before being cast to byte, so basically we can change this to an unsigned byte, without breaking compatibility with existing implementations (until we exceed 128 sessions).
> 
> Using an unsigned byte would allow a maximum 255 Sessions.
> 
> As both endpoints have to consume a byte, increasing this value further would break the protocol.
> 
> Existing connections break when the number of sessions exceeds 128, this will not cause any unexpcected additional breakage.
> 
> I'm not aware of any additional third party implementations of the JERI protocol.
> 
> It's also worth noting that the JERI implementation of today, is much faster and more efficient than JERI released in Jini 2.1, 128 connections would have suffereed from contention, today, this isn't an issue.
> 
> Regards,
> 
> Peter.