How would you pass a socket handle to a new process though? I can see ways of doing it by calling subroutines, but how for a completely new process?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 10 February 2005 00:35 To: [email protected] Subject: Re: [U2] Universe to Web interface 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: <[email protected]> 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: [email protected] > > 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: [email protected] > > 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: [email protected] > > > 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: [email protected] > > > 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: [email protected] > > > > 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 > > > > [email protected] > > > > To unsubscribe please visit http://listserver.u2ug.org/ > > > ------- > > > u2-users mailing list > > > [email protected] > > > 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 > > > [email protected] > > > To unsubscribe please visit http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > [email protected] > > 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 > > [email protected] > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > 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/ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone +44 (0)20 7896 0011 and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Markets Limited and IG Index Plc are authorised and regulated by the Financial Services Authority and, in Australia, by the Australian Securities and Investments Commission. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
