Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 74717 invoked by uid 500); 8 Aug 2003 18:01:06 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 74702 invoked from network); 8 Aug 2003 18:01:05 -0000 Received: from saturn.opentools.org (HELO www.princetongames.org) (66.250.40.202) by daedalus.apache.org with SMTP; 8 Aug 2003 18:01:05 -0000 Received: from localhost (ammulder@localhost) by www.princetongames.org (8.11.6/8.11.6) with ESMTP id h78JW7P07596 for ; Fri, 8 Aug 2003 15:32:07 -0400 X-Authentication-Warning: www.princetongames.org: ammulder owned process doing -bs Date: Fri, 8 Aug 2003 15:32:07 -0400 (EDT) From: Aaron Mulder X-X-Sender: ammulder@www.princetongames.org To: geronimo-dev@incubator.apache.org Subject: Re: RES: RES: "Virtual Hosting" In-Reply-To: <5.1.0.14.2.20030808125623.00a80830@pop.ncsa.uiuc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 8 Aug 2003, Michael Remijan wrote: > I thought it would be assumed that the NIO packages would be the way to go. Well, that's really a different question. Question 1 is, should we do something like I describe below? Question 2 is, regardless of the answer to question 1, should we write a bunch of NIO code to implement our socket handling? I heard the initial releases of NIO were fairly buggy, but I've also heard that 1.4.2 made dramatic strides in addressing that. I don't have any personal experience either way. I'd certainly be open to going that way. But if we don't want to do what's described below, we can start by just relying on Sun's RMI server implementation or something along those lines. Aaron > At 03:18 PM 8/8/2003 -0400, you wrote: > > > Which reminds me, does anyone have any thoughts on the possibility > >and/or wisdom of multiplexing all network communication over a single > >port? You know, HTTP, RMI, JNDI, IIOP, etc. all on the same port (sure, I > >have 7001 in mind)? It makes it darn easy to configure, firewall, tunnel, > >etc. at the cost of (I assume) quite a bit of complexity in terms of > >initially accepting the connection, figuring out the protocol, and sending > >it to the proper handler. > >