Date: Wed, 29 Jan 1997 13:58:28 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: Eivind Eklund <eivind@dimaga.com>, brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd Message-ID: <Pine.BSF.3.91.970129134431.969D-100000@darkstar> In-Reply-To: <9701292040.AA22766@snake.srv.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> But anything after the 512th data byte in the TCP payload will be ignored, > so if your message is 512 bytes long, contains a DCC request in it, > information will be lost that the sender is not aware about (this assumes > the packet is just one IRC message) if the payload size must increase as > a result. > > It is a *much* better idea to redirect IRC to a local TCP port and process > it using a proxy agent. Same could also be said for FTP. > > Darren Darren, In theory, one can construct cases where the FTP logic in the packet aliasing software won't work (IP fragmenting a PORT command, or where the PORT command is split between TCP packets with different sequence numbers, or where the PORT command is in the middle of a packet, and so forth). In practice, these situations are not seen, and the packet aliasing software works for FTP. The system loading is very low, and the software easily scales to situations where there are large numbers of users. I don't know about IRC, but my guess is that the real situation is simpler than the theoretical. Whatever Linux does to handle IRC, I am told that it looks fairly similar to what one does for FTP. Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970129134431.969D-100000>