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: [email protected]
[mailto:[email protected]] 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: [email protected]
> [mailto:[email protected]] 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
> [email protected]
> 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
> [email protected]
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

_______________________________________________
U2-Users mailing list
[email protected]
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
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to