Файл SERVICES
Файл SERVICES подобен файлу HOSTS. Вместо разрешения узлов в IP адреса, он разрешает имена сервисов в номера портов.
Ниже пример, урезанный, файла SERVICES. Для полного списка сервисов вы можете обратиться к RFC 1700. RFC 1700 содержит определение сервисов и их портов:
Echo 7/tcp
Echo 7/udp
Discard 9/tcp sink null
Discard 9/udp sink null
Systat 11/tcp users #Active users
Systat 11/tcp users #Active users
Daytime 13/tcp
Daytime 13/udp
Qotd 17/tcp quote #Quote of the day
qotd 17/udp quote #Quote of the day
chargen 19/tcp ttytst source #Character generator
chargen 19/udp ttytst source #Character generator
ftp-data 20/tcp #FTP data
ftp 21/tcp #FTP control
telnet 23/tcp
smtp 25/tcp mail #Simple Mail Transfer Protocol
Формат файла следующий:
<service name> <port number>/<protocol> [aliases...] [#<comment>]
Вам не требуется читать данный файл, поскольку стек протоколов делает это самостоятельно и прозрачно для вас. Файл SERVICES может быть прочитан с помощью специальной функции стека, но большинство программ не используют эту функции и игнорируют их значения. Например, многие FTP программы используют порт по умолчанию без обращения к функциям стека, для определения номера порта по имени ‘FTP’.
Обычно вы никогда не должны изменять этот файл. Некоторые программы, тем не менее, добавляют свои значения в него и реально используют его. Вы можете изменить их значения, чтобы заставить использовать программу другой порт. Одна из таких программ – это Interbase. Interbase добавляет в файл следующую строку:
gds_db 3050/tcp
Вы можете изменить ее и Interbase будет использовать другой порт. Обычно это не слишком хорошая практика делать подобное. Но это может потребоваться, если вы пишите приложение с сокетами, обычно серверное приложение. Так же хорошей практикой при написании клиентов – это использование функций стека, для получения значений из файла SERVICES, особенно для нестандартных протоколов. Если вхождение не найдено, то можно использовать порт по умолчанию.