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/
