[BXXPwg] Channel Number Range
Wed, 13 Jun 2001 11:40:24 +0100
>> While it would increase complexity of implementation somewhat, is there
>> any other reason that a dynamic mapping (handled by the mapping layer)
>> between BEEP channel and SCTP stream number would create problems?
One issue to worry about is sequence numbering. The sequence number is used
to ensure correct ordering of frames in one direction on one channel.
If there are M channels, and N distinct data flows (SCTP streams in this
case), then sequence number checking should work as expected if:
N = 1 (e.g. RFC 3081)
M = N (the idea of mapping each channel onto a distinct SCTP stream)
M > N, and you map M/N channels onto each data flow - and this mapping is
fixed (e.g. channel 7 frames always travel on data flow 3).
The two places I could see potential for problems are:
M > N, where the mapping is dynamic (e.g. channel 7 frames sometimes travel
on data flow 3, and other times travel on data flow 11)
N > M (e.g. you have one high-traffic channel, yet two TCP connections)
The rules of sequence numbering mean you can only compare the sequence
number of the current frame with that of the immediately previous frame - so
how do you check sequence numbering if a frame is travelling on a data flow
different from the previous frame on the same channel. The two solutions I
can immediately think of are either to forbid this (e.g. forbid M>N with
dynamic mapping and forbid N>M) or to come up with some solution based on
new transport mapping frames, which could help re-combine groups of frames
for the same channel coming in on separate data flows.
>> In practice, a number of the initial SCTP implementation don't provide
>> the entire 0..65536 channel range... is this true of the initial BEEP
>> implementations also?
Clipcode.com's BEEP implementation for MS .NET does support the full range,
but all the values are certainly not expected to be used (even over TCP). It
is supported simply because the channel id is an int.
>> ... are there real situations where one might forsee a need to
>> use channel numbers that exceed 65535?
I think most people would find a few hundred channels to be suitable for
most needs - so I don't see limiting the number of channel for a particular
transport mapping to be a problem. 65535 channels seems ample.