> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Gyle Iverson
> Sent: Wednesday, December 14, 2005 7:43 PM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] UniVerse server socket issues
>
>
> Hello, Tony.
>
> Tony Gravagno opined...
> >Clients need to know the port of a server, so a server
> >absolutely requires a fixed and well-known port.
>
> A server can have a randomly assigned port that is fixed and
> well-known only
> between the client and the server. If the server only exists for
> the benefit
> of one client, it is up to them to figure out how to assign and
> communicate
> the port dynamically. The fixed and well-known port requirement does not
> imply that the assignment is permanent.
>

 FTP transfer is a good example of a dynamic port assignment. Client
commands are passed through server port 21, while the file data is sent to
the server through a dynamically spawned transfer service on a dynamically
assigned port.

> >Why do you need an assigned port for a server?
>
> Think about the problem of a client needing to spawn a unique server on
> demand of the client. Each client may spawn a server dedicated to that
> client. Certainly if one were using real UNIX/Windows processes, one could
> single-thread through a central process and fork a new process,
> however, U2
> products do not allow forking of processes.
>

 No MV products can share the same user heap through forking or child
threading. If you want some options for socket services with MV, e-mail me
directly. execv() is a possibility using a C call, but it's not a fork or
thread solution. I don't want to flood the group with a bunch of potentially
meaningless text.

> >> 2) The other issue with the initServerSocket() is that it
> >> does not recognize when another process already has a
> >> given port open for listening.
> >
> >I haven't read the specs for initServerSocket but if it
> >doesn't return a non-zero for an attachment failure then
> >yes, it's probably broken.
>
> Yep.
>
> >However, in general, a given service should only have one listening
> >process.
>
> Not always true. There are dynamic services too.
>

 FTP once again is a good example.

> >It is valid to have a range of ports which all
> >respond to inbound connections as a single service - that
> >is, multiple servers will be listening to different socket
> >ports, even if they support the same application/transport
> >service.
>
> Interesting idea but it does not help with this issue. Have you tried
> supporting multiple listening sockets in U2? You can not get anywhere
> without a select() or poll() function analogue. While one could spawn
> numerous phantoms, each listening on a unique port, one is left
> with how to
> coordinate data and such between the phantoms. Not a pretty solution.

 No, it's not, but there are ways around this using external pooling. Like I
said, e-mail me. JD3 is a good example of a phantom pool, but phantom
pooling requires a lot of socket reconnections and that just puts unneeded
load on the network sub-system. It's a stable design, but I personally don't
like that architecture when there is a stream of short-term connections.

>
> >Coordination of what ports are in use for a given service
> >should be done by the application, so you should never really
> >get to a failure in initServerSocket.
>
> Try the replication program using port 80. On my system initServerSocket
> returns success even though IIS is currently bound to that port.
>
> >If nothing else you can use netstat to see what ports are in
> >use and use a recognized port that is unallocated.
>
> Yes, but not a solution for this issue.
>
> >Again, if you randomly generate a socket port for a service,
> >how will any client know what port to connect to?
>
> They communicate the port number behind the scenes.

 <broken record>FTP</broken record>

>
> >Good luck.
> >Tony Gravagno
>
> Thanks, Tony.
>
> Best regards,
> Gyle


Glen
batchelg bell_south n.e.t
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to