Серверы без установления логического соединения
Серверы без установления логического соединения также имеют свои преимущества и недостатки. Хотя такие серверы не порождают проблем, связанных с исчерпанием ресурсов, они не могут полагаться на базовый транспортный протокол в отношении надежной доставки. Ответственность за обеспечение надежной доставки должен взять на себя один из участников соединения. Обычно функции по обеспечению повторной передачи запросов в случае неполучения ответа возлагаются на клиентские программы. Если в сервере необходимо разбивать ответы на несколько пакетов данных, в нем также может потребоваться реализовать механизм повторной передачи.
Задача обеспечения надежности с использованием тайм-аутов и повторной передачи может оказаться чрезвычайно сложной. По существу, для ее решения требуется значительный опыт проектирования протоколов. Поскольку протоколы TCP/IP работают в среде объединенной сети, которая характеризуется резким изменением сквозных задержек, применение постоянных значений тайм-аута становится неоправданным. Многие программисты, разрабатывающие собственные схемы обеспечения надежности, усвоили этот урок на своем горьком опыте. Приложения обычно проверяются в локальной сети, отличающейся высокой надежностью и небольшим изменением задержки. После переноса приложений в глобальную объединенную сеть, характеризующуюся более низкой надежностью и значительным изменением задержки, простые схемы определения тайм-аута повторной передачи перестают работать. Стратегия повторной передачи, которую можно применить в среде объединенной сети, должна быть адаптивной. Поэтому для обеспечения работы приложений, основанных на использовании протокола UDP, в глобальной сети Internet в них необходимо реализовать такую же сложную схему повторной передачи, какая используется в протоколе TCP. Поэтому начинающим программистам рекомендуется применять транспортный протокол с установлением логического соединения.
Поскольку протокол UDP не гарантирует надежной доставки, применение транспортного протокола без установления логического соединения связано с необходимостью обеспечения достаточно высокой надежности за счет использования прикладного протокола, основанного на применении сложной и развитой методики, известной под названием адаптивной повторной передачи. Задача внедрения средств адаптивной повторной передачи в уже существующее приложение является сложной и требует значительного опыта.
Еще один фактор, который может повлиять на выбор проекта без установления или с установлением логического соединения, связан с тем, требуется ли для данной службы широковещательная или групповая рассылка. Поскольку протокол TCP обеспечивает только двухточечную связь, он не дает возможности использовать в приложениях средства широковещательной или групповой связи; для таких служб требуется протокол UDP. Поэтому любой сервер, который принимает или отвечает на запросы, передаваемые с помощью средств групповой связи, должен использовать протокол без установления логического соединения. На практике администраторы большинства сетевых узлов стараются, по возможности, исключить применение широковещательной рассылки. К тому же ни один из стандартных прикладных протоколов TCP/IP в настоящее время не требует групповой рассылки. Однако в дальнейшем могут появиться приложения, в которых будут шире применяться средства групповой связи.
Нарушения в работе, надежность и отказ от поддержки состояния
Как было описано в главе 2, сопровождаемая сервером информация о том, как проходят существующие сеансы взаимодействия с клиентами, называется информацией о состоянии. Серверы, не сопровождающие информацию о состоянии, называются серверами, не поддерживающими состояние, а серверы, сопровождающие информацию о состоянии, называются серверами, поддерживающими состояние.
Задача выбора проекта с поддержкой или без поддержки состояния связана с решением проблемы обеспечения надежности, особенно если в проекте используется транспортный протокол без установления логического соединения. Напомним, что в объединенной сети сообщения могут быть продублированы, задержаны, потеряны или доставлены в ином порядке по сравнению с исходным. Если транспортный протокол не гарантирует надежной доставки, как в случае применения протокола UDP, прикладной протокол должен быть разработан таким образом, чтобы он смог обеспечить надежную доставку. Кроме того, должна быть очень тщательно продумана реализация сервера, чтобы в серверной программе не возникла зависимость от состояния (и не произошло снижение эффективности работы).