On Sun, 30 Nov 2008, Joe Reichman wrote: > Hi, > > In TCP/IP does a concurrent server need create a socket for every subtask > ???? >
I think that your terminology may be a bit off. A socket is a single communications path in TCPIP. Normally, a server will first BIND to a port, then LISTEN on that port. This is not a socket. When a request comes in, the code needs to ACCEPT. At this point you have an actual socket. Quite often, in the UNIX world, what is done is that the main process (task) will do all of this. It will then fork() or spawn() another process and give ownership of the socket created above to that process. The new process (called the child) will do all the TCPIP functions that need to be done. So, I think the answer to your question is NO. The main task would do the BIND, LISTEN, and ACCEPT. At that point, it could ATTACH a subtask and give that subtask the SOCKET to talk to the client. In some servers, they don't even do the above. It is possible to use asynchronous TCPIP functions and "multitask" the services in a single z/OS task. But it takes a lot more, clever, programming and I doubt it is done very often. Does this help any? Or have I just confused things more? -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
