From owner-freebsd-hackers Wed Jan 29 14:46:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27201 for hackers-outgoing; Wed, 29 Jan 1997 14:46:33 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27188 for ; Wed, 29 Jan 1997 14:45:54 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA16901; Thu, 30 Jan 1997 09:45:39 +1100 (EST) Date: Thu, 30 Jan 1997 09:45:38 +1100 (EST) From: "Daniel O'Callaghan" To: Charles Mott cc: Darren Reed , Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@freebsd.org, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Charles Mott wrote: > 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. People coding these in-stream proxies might also like to look at the slirp code There are quite a few transparent proxies in there. Danny