| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Nodelist-Flags |
Hello Michiel, > MvdV> Why am I making a point of this? To show that an > MvdV> upper limit must be specified, > Within a short time you will then discover that the upper > limit is too low and there are problems again. There is no foolproof way to avoid that. If one does not specify an upper limit, programmers will /assume/ one and the situation will be worse because they all will assume something different. The only thing one can do is specify a ridiculously high limit and pray that it will not be exceeded during the lifetime of the product. > You mention 128 kb over ISDN, this is without datacompression, > do we need a new baudrate field if we start transfering > data at aprox. 400 kb with compression over ISDN. No. Speed should be measured at the physical level after any compression. Rates measured on the uncompressed side are meaningless since compression rates depends on the type of data. Calling it 400 kb is sales talk. Don't get me wrong. I am /not/ advocating an upper linit of 128 kb. The limit should be much higher. I a thinking in the order of 1Gb/s or so. > In my optinion we only need capability flags. Lets stop the > baudrate bidding at the point were we are now. > > Youre right with this point, the baudrate field belongs to > ancient modems that needed it. Exactly my point of view, but it is too late. The djin is out of the bottle. All we can do now is damage control. Cheers, Michiel --- InterMail 2.29k* Origin: vlist{at}hccfido.hcc.nl (2:280/5555) SEEN-BY: 201/0 200 209 300 329 400 407 411 505 600 203/600 204/450 700 205/0 SEEN-BY: 206/0 270/101 490/21 633/267 270 @PATH: 280/5555 500/9 3 396/1 270/101 201/505 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.