[BXXPwg] trouble with pending requests

Wesley Michael Eddy we686498@oak.cats.ohiou.edu
Thu, 3 Aug 2000 15:52:23 -0400 (EDT)


  After thinking a bit about the discussion in the WG meeting today and
speaking with some people, I believe that response frame headers must
contain the channel number.  This is why:

1) Current implementations must use the serial number of the pending
request to pass a response frame to the proper channel.  So in other
words, a data structure mapping serial numbers of pending requests to
their proper channels is needed.  This is just a silly thing to do when
the channel number could simply be passed in the frame header as it is
with responses, simplifying things a bit and having the added bonus of
avoiding problem #2.

2) So, there has been discussion of what for lack of any better term I
will call a monologue conversation between two BXXP peers.  This occurs
when only one peer really needs to be sending messages.  The way people
have suggested to do this is to use a profile where requests don't have to
be responded to.  This way the "speaking" peer can just keep sending out
its requests as long as it wants to.  The only problem with this occurs
when the implementation treats these as pending requests and starts
throwing them in whatever structure it uses to match responses up with the
channels they belong in.  Obviously as these requests are never responded
to, this structure begins to take up space, not to mention the fact that
the serial number space is finite, so without some garbage collection
the implementation will waste a lot of memory and potentially run out of
serial numbers.

  Of course if the implementation is smart enough to not put pending
requests into its structure when it sees them going out on a channel where
responses won't occur, then it can avoid the pitfalls of #2, but this is
still sloppy because then a channel must either always require responses
or never require responses, which seems a bit limiting.

  In my opinion, #1 alone is enough to warrant change in the response
frame header, and #2 is downright compelling, so as I am unable to attend
the WG tommorrow morning, I hope that this issue will be addressed by
someone else in my place.