Re: [U2] Server Socket logic
You are quite right , you can not - but you can not fork in u2, phantom is as good as it gets so you would have to talk to the client on a different socket, and the new phantom would continue listening on the standard one. Very much the other way round to how you would normally do it. Personally i would write a middleware tier that did all the comms, and communicated back to u2 via a set stack of connections (connection pooling if you will) this would give proper socket comms and good scalability. Actually what i would do, and by far the easiest, is do a web service in .net and use uniobjects.net with connection pooling, tho sometimes i suppose a raw socket is more appropriate than a http connection. From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Glen B Sent: 14 January 2011 04:01 To: U2 Users List Subject: Re: [U2] Server Socket logic I was not aware that you could pass file handles between phantoms and process or other phantoms. That's a no-brainer for Linux fork(), but in most of the MV socket services I've implemented I either: 1) use an inetd/Winetd tool to handle the socket-based muxing and all you have to do is make simple command-line calls to routines(or a single service program). They use stdin/stdout via normal keyboard and screen I/O. Gotta be careful with local echo, though. 2) Have the client first connect to the master (accept()ing process), get an available client phantom port from the pool and then reconnect to that idle phantom on that specific port# to handle the request. #1 makes the solution the easiest to code for and expand, IMO. #2 makes worker management a primary headache but it can all be kept inside the environment. Both solutions can either serve multiple applications from one port based on request data or they serve specific apps on different dedicated ports. A third option is to use request/response file queuing and what ever media type you feel comfortable with. Check out MVWWW on SourceForge for an idea of what I did there. It takes a little more leg work and the interesting(and potentially insecure) feature is that you can easily inject requests and hijack responses at the cross-roads using pretty much any tool at any layer. Local sockets aren't technically any safer, mind you, but it's much much simpler to get a text file into a directory than to spoof network packets. GlenB On 1/13/2011 11:28 AM, Symeon Breen wrote: PHANTOM From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: 13 January 2011 15:42 To: U2 Users List Subject: Re: [U2] Server Socket logic Yes, but how do you fork in universe? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3376 - Release Date: 01/12/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3377 - Release Date: 01/13/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Server Socket logic
I agree with Glen and Symeon - don't do socket work in the DBMS unless you control the protocol and it's dirt-simple. By far the best way to do this is to create a middle tier using tools that are designed to do this, and communicate with the DBMS as a data source. Glen and Symeon and I have been down this path before. Experience has influenced our recommendation. I hope you can benefit from the time we've spent in this area. It's not easy do do this with other tools, but IMO it is better because the tools are more stable, better supported, and you can get help from a much wider audience, including books and websites. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula RD sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno From:Symeon Breen Personally i would write a middleware tier that did all the comms, and communicated back to u2 From: Glen B ... in most of the MV socket services I've implemented I either: 1) use an inetd/Winetd tool to handle the socket-based muxing and all you have to do is make simple command-line calls to routines... ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Server Socket logic
I was not aware that you could pass file handles between phantoms and process or other phantoms. That's a no-brainer for Linux fork(), but in most of the MV socket services I've implemented I either: 1) use an inetd/Winetd tool to handle the socket-based muxing and all you have to do is make simple command-line calls to routines(or a single service program). They use stdin/stdout via normal keyboard and screen I/O. Gotta be careful with local echo, though. 2) Have the client first connect to the master (accept()ing process), get an available client phantom port from the pool and then reconnect to that idle phantom on that specific port# to handle the request. #1 makes the solution the easiest to code for and expand, IMO. #2 makes worker management a primary headache but it can all be kept inside the environment. Both solutions can either serve multiple applications from one port based on request data or they serve specific apps on different dedicated ports. A third option is to use request/response file queuing and what ever media type you feel comfortable with. Check out MVWWW on SourceForge for an idea of what I did there. It takes a little more leg work and the interesting(and potentially insecure) feature is that you can easily inject requests and hijack responses at the cross-roads using pretty much any tool at any layer. Local sockets aren't technically any safer, mind you, but it's much much simpler to get a text file into a directory than to spoof network packets. GlenB On 1/13/2011 11:28 AM, Symeon Breen wrote: PHANTOM From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: 13 January 2011 15:42 To: U2 Users List Subject: Re: [U2] Server Socket logic Yes, but how do you fork in universe? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3376 - Release Date: 01/12/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
