Tom Perrine wrote:
>Truly, about the only use I really have for multiplexed channels would
>be to make it easier to do "urgent" and out-of-band stuff.
Actually, that's a really interesting issue. Here's a neat (and sh&t simple)
way to handle it:
1) client is connected to server
2) client is sending "normal priority" stuff
3) client gets some "urgent" stuff in its input queue
3a) client puts urgent stuff aside (logically; this could be in-memory or
in a queue-file, or whatever)
4) client (at whatever interval after getting the urgent stuff makes sense
for it - settable) goes "DUH! must handle urgent stuff!"
5) client disconnects from server
6) client sends the urgent stuff
7) client purges its urgent queue
8) GOTO 1
This is a REAL simple and convenient way of handling urgent stuff and
has the property of handling bursty urgent messages well because there
is a small buffering on the client. It also behaves well under DOS attacks
where the server or client is getting flooded - if either floods too badly the
reconnects drop off, and eventually the queues flush - which sounds ugly
but the reality is who needs a queue full of "HELP !I AM OVERLOADED!"
messages. :)
There may be something wrong with the protocol suggested above,
but I don't think so. I directed my engineers at NFR to use that approach
for one of our products but instead they came up with something involving
tagging records and a load more complexity and we never got to find
out if it was better because, well, it never worked at all... ;)
mjr.
---
Marcus J. Ranum - Computer and communications Security Expertise
mjrat_private (http://www.ranum.com)
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Dec 05 2002 - 15:45:05 PST