Шрифт:
Сокет типа «один-к-одному»
Данный тип сокета был разработан специально для облегчения переноса существующих приложений с TCP на SCTP. Его модель практически идентична описанной в главе 4. Существуют, конечно, некоторые отличия, о которых следует помнить (в особенности, при переносе приложений):
1. Все параметры сокетов должны быть преобразованы к соответствующим эквивалентам SCTP. Чаще всего используются параметры
2. Протокол SCTP сохраняет границы сообщений, поэтому приложению не приходится кодировать их самостоятельно. Например, приложение, основанное на TCP, может отправлять записи, чередуя двухбайтовые поля длины с полями данных переменной длины (каждое поле записывается в буфер отправки отдельным вызовом
3. Некоторые TCP-приложения используют половинное закрытие для извещения собеседника о конце считываемых данных. Для переноса таких приложений на SCTP потребуется переписать их таким образом, чтобы сигнал о конце данных передавался в обычном потоке.
4. Функция
Типичное приложение, работающее в стиле «один-к-одному», будет вести себя так, как показано на временной диаграмме рис. 9.1. Запущенный сервер открывает сокет, привязывается к адресу, после чего ожидает подсоединения клиента в системном вызове
Рис. 9.1. Временная диаграмма для сокета SCTP типа «один-к-одному»
Сокет SCTP типа «один-к-одному» является IP-сокетом (семейство
Сокет типа «один-ко-многим»
Сокет типа «один-ко-многим» дает разработчику приложения возможность написать сервер, не использующий большого количества дескрипторов сокетов. Один дескриптор для такого сервера будет представлять несколько ассоциаций, подобно сокету UDP, способному принимать дейтаграммы от множества клиентов. Для обращения к конкретной ассоциации, установленной для сокета типа «один-ко-многим», используется идентификатор. Идентификатор ассоциации представляет собой значение типа
При написании приложения, использующего сокеты данного типа, рекомендуется помнить о следующих важных моментах:
1. Когда клиент закрывает ассоциацию, она автоматически закрывается и на стороне сервера. При этом удаляются все сведения о состоянии ассоциации в ядре.
2. Только при использовании типа «один-ко-многим» возможна передача данных в третьем и четвертом пакетах четырехэтапного рукопожатия (см. упражнение 9.3).
3. Вызов
4. Приложение должно использовать функции
5. При вызове одной из функций отправки данных используется основной адрес получателя, выбранный системой в момент установки ассоциации (раздел 2.8), если вызывающий процесс не установит флаг
6. Уведомление о событиях для ассоциации может быть включено по умолчанию, так что если приложению не требуется получать эти уведомления, оно должно явным образом отключить их при помощи параметра сокета