> -----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/