OK. That's what I thought. UV is in the same situation as all the other flavors. If you can't pass a file handle between processes, then you can't effectively create a multi-client service by using just the sockets API. There have been numerous web/socket architecture examples published, in terms of code and/or postings on C.D.P.
JD3 is a Java-focused socket service that uses a port gateway, which redirects(client disconnects and then reconnects) incoming connections from a master listener to 'child' listeners. This is a stable method, which does not require sessions to be initiated. The biggest drawbacks are the reconnect lag, port firewalling issues, and requirement of the port master to constantly keep up with who/what is really running on the MV side. This is considered an internal architecture. No non-MV components are needed. Coyote is an internal HTTP service all in its own world. <hat off to Doug> FlashCONNECT is an HTTP POST/GET service that has client-side and server-side services running. I don't know all the details of how the 2 services communicate, but the request is sent to a local(webserver->CGI->local) service. That service is already connected to matching services in MV. The communication paths are pre-established, so there is zero lag between CGI request and MV processing. The only problem there is the fact that the communication paths are pre-established. It's a dual-edged sword. Monitors have been added to recent releases, to deal with previous load and license balancing problems. This is the most effective mixed architecture I've seen so far. MVWWW is an open communications framework that utilizes an open mixed architecture. The 2(or 3 if you separate the client component) architecture 'zones' are separate. The CGI(or client), the spooler, and the service zones can be separated and used by themselves for other purposes. This modularization allows flexibility in integration. However, it also leads to security and content management issues. I, as a developer, prefer this style of architecture over mixed or internal-only simply because of the flexibility. RedBack.. hm.. never touched it. One of these days I'll get around to it. I run FlashCONNECT here mostly because I'm still running D3. Times'r changing though. I develop MVWWW on my OpenQM developer box. When Doug releases Coyote for OpenQM, I'll definitely be running it through the hoops too. When someone asks "how I do pull MV data using my browser", I like to sit back and watch the fur fly. I lost count of the number of methods discussed for getting MV data into a browser. Maybe one of these days a web-based communication integration wizard will be created. Until then, I wish more of this kind of information was compacted, indexed, and published on the web. If anyone has any further comments or questions for me, e-mail me directly. I've wasted enough list space. Hey Chuck.. you lurkin? I got another article idea for ya. <G> -Glen http://picksource.com webmaster [at] mvdevcentral [dot] com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Simon Lewington > Sent: Thursday, February 10, 2005 11:42 AM > To: [email protected] > Subject: Re: [U2] Universe to Web interface > > > Glen B... > > > > If you can truly pass a UV socket handle to another UV process, then > > there's no reason why anyone can't write a stable "multi-threaded" socket > > server directly in UV BASIC. Is this true? > > > > Kevin P Lynch... > >> > > > here is the appropriate manual : > > > http://publibfi.boulder.ibm.com/epubs/pdf/25119080.pdf > > You most definitely *cannot* pass a UV socket handle to another UV process. > > Simon > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
