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/
