Glen, I have'nt done extensive research on it, but from the samples provided by IBM using a dimensioned array, I believe UV would manage the forking off the sockets itself. Don't quote me on this though. I'll dig out the sample I have and send it on to ya... If you want you can test it out on my system and play since you don't have access to a UV box. For you no problem.
Vance ----- Original Message ----- From: "Glen B" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Wednesday, February 09, 2005 5:21 PM Subject: RE: [U2] Universe to Web interface > Kevin, > > I read through the PDF. However, it is not clear on how the handles can be used. A lot of the API's I've seen have the same level > of functionality, but they all lack the ability to pass handles from the acceptor process to a totally separate user process. This > isn't really an issue of the API, it's more of a user environment issue. You can pass the handle value itself, but the other process > loses the 'meaning' of the handle and it just becomes a worthless string. An example would be launching a new phantom and passing it > the handle variable, after accepting an incoming connection. The same situation occurs when you pass any kind of memory reference(or > offset) to anything outside the current user heap. Unix fork()ing generates a mapped/duplicate user heap, so all file/handle > references still work properly without having to munge underlying memory addresses. 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? If so, I want a developer copy so I can try to blow it up. :P <eg> > > -Glen > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Kevin P Lynch > > Sent: Wednesday, February 09, 2005 3:52 PM > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] Universe to Web interface > > > > > > you manage the connections from basic, the whole interface is a > > set of basic extensions. basically you open a socket on a port , > > accept a connection on that socket and write to the socket. > > > > here is the appropriate manual : > > http://publibfi.boulder.ibm.com/epubs/pdf/25119080.pdf > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Glen B > > Sent: Wednesday, February 09, 2005 2:31 PM > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] Universe to Web interface > > > > Must be nice. I wish that capacity existed in every flavor. It would make > > the integration world a breeze. Well my real question would be; is the > > service external or internal? I'd be interested in knowing how the socket > > service is laid out. Do you have to manage connections yourself? How are > > socket handles passed to children under multiple listening conditions? Or, > > do you tell the UV service to listen 4-at-a-time, on port XXXX, and then > > call <MYAPP> when a connection is accepted? > > > > -Glen > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of Kevin P Lynch > > > Sent: Wednesday, February 09, 2005 1:19 PM > > > To: u2-users@listserver.u2ug.org > > > Subject: RE: [U2] Universe to Web interface > > > > > > > > > Glen, > > > The UV socket server interface works the same in Unix and Windows, I > > > have server programs running in both environments with no changes. > > > > > > Kevin Lynch > > > The Systems House > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Glen B > > > Sent: Wednesday, February 09, 2005 12:04 PM > > > To: u2-users@listserver.u2ug.org > > > Subject: RE: [U2] Universe to Web interface > > > > > > Stewart, > > > > > > Socket implementations don't work across flavors. I've written many > > > socket apps for D3, but even the small differences in the socket > > > designs between Win and *nix causes problems. Sockets are easy to > > > implement, but only if you want to maintain separate code-sets for Win > > > and *nix under each flavor you want to support. I won't get into the > > > details here, since I'm not familiar with the UV socket API. Service > > sockets are meant for the O/S, not Pick. > > > Doug Dumitru bit the bullet and wrote his own TCP stack in Pick ASM. > > > That is about the only way I would recommend even contemplating Pick > > > server sockets. For clients, the socket APIs are fine. The calls are > > > nearly identical between Win and *nix. The only issue there is > > > blocking control, which unfortunately most of MV socket developers are > > unknowledgeable of. > > > OK...I'm not going to get into that... <meditating> > > > > > > The SELECT can be handled several ways, but it still comes down to > > > global locking of some kind. Another method is to use a stack file, > > > instead of a directory. Since there's no need to close the pick file > > > pointer, the overhead of opening(refreshing) and closing a local directory > > is eliminated. > > > The only problem here, is the fact that every phantom has to lock the > > > file before it checks any kind of stack status. That's not a problem > > > on the MV side, but it can cause general service issues. If the MV > > > file locks aren't file > > > system(flocks/perms) as well, then the spooler could easily corrupt > > > the stack with phantoms polling it constantly. Then, you end up having > > > to write a stack manager to deal with I/O. Yes, all of that would work > > > much better than directory polling. It's a lot more design work and > > > can tend to be debugging unfriendly. > > > > > > Another method, which was implemented in a prior release of MVWWW, > > > was through the use of O/S TCL command tools. Instead of spooling the > > > request, the request was posted directly to the HTTP service via > > command-line TCL. > > > The biggest drawbacks there were session init lag and overall insecurity. > > > Anyone could telnet to the local Inet service and hack into Pick > > > through the HTTP service. > > > Starting and stopping sessions ended up creating a lot of load under > > > D3, since it's VME based. It could be that this is the answer for UV, > > > UD, and possibly mvBase. My only concern would be the user permissions > > > required to make something like this happen in UV. I could be wrong > > > though, I'm still a UV newbie. > > > > > > Finally, there was the gateway/manager I wrote in C and the > > > stand-alone MV TCP/IP listener. The gateway maintained a list of > > > available IP ports and provided a transparent TCP/IP bridge for the > > > CGI client, into Pick. The only problem there was the use of a shared > > > segment to store the port map. I actually ported it to Win32. And it > > > ran like doo-doo. After about 10 hits per second, the Linux port handler > > went bonkers and stuff stopped working. > > > The Win32 threaded version never left Alpha, before I dropped it in > > > the shredder. I have to say, this was the speediest Linux solution by far. > > > Response time was sub-second, provided the web app didn't take too long. > > > Maybe in a couple more years, when I get some more VC++ knowledge > > > under my belt I'll try it again. > > > > > > Regards, > > > > > > -Glen > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of Stewart > > > > Leicester > > > > Sent: Tuesday, February 08, 2005 11:37 PM > > > > To: u2-users@listserver.u2ug.org > > > > Subject: RE: [U2] Universe to Web interface > > > > > > > > Thanks for the reply. I wasn't critiquing so much as I'm curious: I > > > > was called in to accomplish this in a quick and dirty fashion 5 or 6 > > > > years ago and after a few days ended up with something very similar > > > > to what you describe. > > > > > > > > I wasn't happy with a loop which continuously performed SELECTs but > > > > SLEEPs seemed to slow it down too much. I recall looking for > > > > something I could use as a blocking read operation and believe I tried > > pipes. > > > > IIRC they worked OK but sometimes operations hung up. I thought of > > > > using sockets but never had the chance to try. Perhaps you could get > > > > it to work with sockets and let me know what you find. :-) > > > > > > > > Stewart > > > > -- > > > > Stewart Leicester | http://www.ThreatFocus.com > > > > V.P. Engineering | mailto:[EMAIL PROTECTED] > > > > Threat Focus, Inc. | 925-551-0130 Voice > > > > "Knowledge is your best defense" | 509-695-1373 Fax > > > > ------- > > > > u2-users mailing list > > > > u2-users@listserver.u2ug.org > > > > To unsubscribe please visit http://listserver.u2ug.org/ > > > ------- > > > u2-users mailing list > > > u2-users@listserver.u2ug.org > > > To unsubscribe please visit http://listserver.u2ug.org/ > > > > > > ______________________________________________________________________ > > > This email has been scanned by the Inbound TSH Mail Filter Please > > > Report any issues to [EMAIL PROTECTED] > > > ______________________________________________________________________ > > > ------- > > > u2-users mailing list > > > u2-users@listserver.u2ug.org > > > To unsubscribe please visit http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > > > > ______________________________________________________________________ > > This email has been scanned by the Inbound TSH Mail Filter Please Report any > > issues to [EMAIL PROTECTED] > > ______________________________________________________________________ > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
