On Wednesday, 05/17/2006 at 09:54 EST, Tom Duerbusch <[EMAIL PROTECTED]> wrote: > If I remember correctly, when you FTP to port 21, the FTP server > responses with another port that you should use for the rest of the FTP > session. This keeps port 21 from being tied up during long FTP > sessions. Right?
No. Your client maintains a session with port 21. Data transfer uses another set of ports. (Port 20 on the server side.) > OK, how does this concept work with Telnet, port 23? Is my client > being transferred to other ports? Are all of my hundreds of telnet > sessions, all using the same port 23? Are they using it "one at a > time"? When I hit enter, and it takes 5-10 seconds to get a response, > is my client tieing up the port so no one else can use it? All of that, > just doesn't sound right. Is there a concept of "shared ports"? Yes, ports are shared, but each client is represented by a separate socket on that port. Multiple *users* (servers) sharing a port requires additional configuration to avoid port-in-use errors. > Just how it short tasks like telnet (tn3270), and I guess, webservers > (port 80), handle this? Where is the documentation that may explain how > things are done, for what service? The specific internal design details of each server are not published, but I can tell you that the telnet server has two asynchronous interfaces: Socket and Diagnose 0x7C (Logical Devices). When a SELECT wakes up and indicates socket activity, it pulls the data from the client and relays that to the CP LDEV. When CP speaks on the LDEV, the SELECT again wakes up and the server sends that data to the corresponding client. Webservers benefit from asynchronous file I/O. But on CMS the FSREAD and FSWRITE file system are synchronous. For apps that just want to read/write raw block data, VM provides the *BLOCKIO system service (used by SFS and DB2). If the server has good asynchronicity, then a single client won't monopolize the server. For VM TCP/IP, you may benefit from defining multiple virtual CPUs in TCPIP and assigning the device drivers to the other CPUs, leaving the base CPU for the telnet server and the non-I/O parts of the stack. (Only do this if VM has more than one CPU available to it.) Alan Altmark z/VM Development IBM Endicott
