The client can easily see the pipe is full (with "full" designated by the
user).
>It is much more efficient for the server to tell the client when another
>channel is needed, since the client can't tell if packets are being
>dropped on the server side. Without BACP, if the amount of data coming
>from the server to the client is just about enough to fill the current
>pipe, the client would bring up a channel, not use it, drop the channel,
>see the pipe about full, bring up a channel, etc. That is bad, so BACP
>exists.
The gear I've used let's me speciify threshhold levels, timers, all sorts
of stuff. I can tweak how it brings up that second channel, and how it
tears it down. I still maintain the client can autonomously control how
many channels it needs effectively. The server needn't enter the picture,
and in fact would also be susceptible to the add/drop problem you mention
above. Given the joys of each vendor's interpretation of RFC's, we get to
fight with BadNetworks and Lucend about who's broken their BACP
implimentation. Don't use a negaotiated protocol, you don't have
interoperation issues.
Well, let's just say we agree to disagree. :-)
(I have a very bad taste in my mouth from BACP after dealing with Ascend vs
Lucent in early implementations and the current BN vs Lucend problems.
After many headaches and lots of new gray hair I say screw it and let the
client do the work.)
jon
_____________________________________________________
|Jon Rust | VCNet, Inc |(805) 383-3500|
|jpr@vcnet.com | | www.vcnet.com|
|---------------------------------------------------|
| "So I got that goin' for me, which is nice." -CS |
|___________________________________________________|
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>