[BXXPwg] Whither serial and seqno?

Sarveshwar Rao Duddu duddu@vsnl.com
Mon, 24 Jul 2000 22:56:57 +0530


Steve Harris wrote:

> "Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:
>
> [...]
>
> > the next question is whether each channel should have their own serial
> > number space or whether they should be unidirectionally or bidirectionally
> > unique. the choice made was unidirectionally unique because it's not any
> > harder to generate than the other three and it means we don't have to pass
> > the channel number back on a response.
>
> It seems to me that it is _is_ harder to generate a number unique to
> all existing channels - arguable more so in a multi-threaded
> library. If a BXXP library exposes an interface that allows requests
> to be created on a given channel, and most of that channel's data
> structures are more or less thread-local, then there must be some
> shared table of used/available serial numbers that each channel must
> lock down to a fresh serial number. Now, it's possible to say that the
> allocation of that serial number is deferred until the first frame
> gets passed from a channel thread to a shared output thread (thinking
> of a scheme like mod_bxxp), but that's more complicated that just
> saying that each channel manages its own set of serial numbers.
>

    Sender's problem of generating a unique serial number can be
    probably solved by dividing the serial number space into
    partitions, one for each possible channel.
    That is, for every channel, number of possible requests at a time
    = 2147483648 / 128 = 16777216. quite a big number,
    and you can loop back too. so this is not a problem.


>
> I agree that you'd have to pass the channel back along in the
> response, but that actually makes "routing" the frame easier! At
> present, you have to look up the response serial in a shared set of
> "outstanding requests" to get the channel number, again locking down
> some shared data that the output thread would likely be contending for
> as well.
>

    this is a major problem. channel level uniqueness will be easier for
implementation.

>
> --
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
>
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg