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 <peter.firmst...@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.
