Kurt As I sent off my previous post, I noticed that I'd overlooked your last sentence. But as it was going to need a bit of explanation, I had to put it off for a while.
> Can anyone ... ? I expect many can. Perhaps what you wanted to say was "Would anyone (be so kind as to / care to) ...?". > ... give me a brief explanation when and how this file is used? - What I'm about to say isn't necessarily 100% true but it must be close and it's my interpretation. Somewhere back in the days that the sockets API was being designed there was a decision that no number need be specified without being obtained by a lookup from a token. This is an obvious provision in the case of the destination IP address since it is much better to refer to the name of an IP node rather than always having to know the address of at least one interface on the node. It's now important to know that there is a structure which needs to be populated with two key numbers before it is used. This is the structure used by the CONNECT() call of a client program when using the client-server concept. The first number is the destination IP address and the second number is the port number which represents the service provided by the server program. - You may well be aware that, when using a TELNET or FTP client, you can specify either a name, a sequence of tokens separated by dots, or the IP address of an interface. Either is valid as a way to specify the "destination" in the same location following the command. In the case of your browser, you can specify either a name or an IP address between the double-slash and the first single-slash, if any, in the URL character string. There is some standard logic wrapped around sockets API calls which takes the character string which represents the "destination" and first tries to treat it as a "dotted decimal" IP address using the INET_ADDR() call. The INET_ADDR() call, which is supported purely by logic without any external references, either returns an internal version of the IP address or zero for "failure". If "failure" is noted, the next call is the GETHOSTBYADDR() call which tries to convert the character string to, logically, a list of IP addresses. Each of the returned IP address - and, of course, there may only be one - is tried in turn in order to create the TCP connection. What happens with the GETHOSTBYADDR() call depends on how the "resolver" is configured. It could be a lookup in data sets available on the node supporting the client program or it could involve IP traffic to a name server node. - Before any CONNECT() calls can be made by a client program, the port number needs to be determined. Also, in the initialisation of the *server* program, the port number at which the service is to be provided needs to be determined and it is set in an identical structure to the one mentioned above and used in a BIND() call. This is where the GETSERVBYNAME() call comes in. The token which represents the application, the service, is converted to a port number. Thus "ftp" is converted to 21 and "telnet" is converted to 23 - and "http" is converted to 80 - if the usual transformations are defined in the generically named ETC.SERVICES data set, in your case TCPIP.ETC.SERVICES but on my PC, and possibly on your PC, in the following: C:\WINDOWS\system32\drivers\etc\services Note that the lookup needs to be qualified in the call by the transport protocol to be used, "tcp" or "udp". - Note also that everything I have explained above is what happens in the case of IPv4. One of these days, I'm going to have to work out the IPv6 equivalent - or, more precisely, the joint IPv4-IPv6 equivalent. - Just to round the topic off, there is the generically named ETC.PROTO data set which could be used by a program, client or server, in order to determine the protocol number to be used in a SOCKET() call. However, it is usual to specify a "type" code in the SOCKET() call and let the system determine whether, for type "stream", TCP should be used or, for type "datagram", UDP should be used. Probably you can find this data set on you PC under the following path: C:\WINDOWS\system32\drivers\etc\protocol - Incidentally, if you don't really understand for what your TCPIP.ETC.SERVICES file is used, I'm rather surprised you are contemplating changing it! - Chris Mason On Wed, 26 Oct 2011 11:14:53 -0700, Kurt Eastwood <[email protected]> wrote: >Hello, > >Thanks to any and all who consider my question. > >Can the TCPIP.ETC.SERVICES file be changed at will or are there special >considerations for changing this file , such as task usage, back up, etc that >must be taken into account before changing this file? > >Can anyone give me a brief explanation when and how this file is used? > >Thanks for any help anyone is willing to offer. > >Kurt ---------------------------------------------------------------------- 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
