>> Kevin Lentin writes:
>> > What I want is for interactive telnet sessions to be responsive while an
>> > ftp or http request is being processed. Under term, packets were
>> > prioritised based on client. I'm expecting you can't do that in tcp but
>> > size should be a good approximation.
>>
>> I haven't tried linux packet scheduling yet, but my guess is that, since
>> the scheduler can only control transmit queues, interactive sessions'
>> performance while doing FTP transfers over serial links will not be much
>> improved. Am I right?
>>
>> Unless, of course, the other side is Linux too, which happens more and
>> more often to me. ;)
Mark> Given that FTP is usually ports 20/21, HTTP is usually 80, and
Mark> Telnet is almost
Mark> always 23, a packet scheduling based on port number, where port
Mark> 23 is given
Mark> the highest priority, and all other ports are given a lower
Mark> priority,
Mark> should be possible...
It is. Using the firewall rules you can set the TOS bits. As Alexeej
Kuznestov once expalined to me:
Dumb applications does not set any TOS, so that normal data have
priority 1. Telnet, rlogin (seems, almost all implementations) sets it to
LOWDELAY and, hence, goes via band 0 (the highest priority).
ftp sets LOWDELAY for control channel and HIGHTHROUPUT for data channel,
that puts it to the lowest priority band (it is not quite corect,
because ftp_data is not background channel, but the approximation
is pretty good). The same thing is made by sendmail and
innd(LOWMONETARYCOST is also mapped to band 2).