Надежная передача данных по протоколу SCTP

Протокол передачи с управлением потоком объединяет преимущества протоколов TCP и UDP

Протокол передачи с управлением потоком (Stream Control Transmission Protocol, SCTP) − это надежный транспортный протокол, который обеспечивает стабильную, упорядоченную (с сохранением порядка следования пакетов) передачу данных между двумя конечными точками (подобно TCP). Кроме того, протокол обеспечивает сохранение границ отдельных сообщений (подобно UDP). Однако в отличие от протоколов TCP и UDP протокол SCTP имеет дополнительные преимущества, такие как поддержка множественной адресации (multihoming) и многопоточности (multi-streaming) - каждая из этих возможностей увеличивает доступность узла передачи данных. В этой статье мы познакомимся с основными характеристиками протокола SCTP ядра Linux® 2.6 и рассмотрим исходный текст программ сервера и клиента, демонстрирующий возможности протокола по многопоточной передаче данных.

М. Тим Джонс, инженер-консультант, Emulex

M. Тим Джонс (M. Tim Jones) является архитектором встраиваимого программного обеспечения и автором работ: Программирование Приложений под GNU/Linux, Программирование AI-приложений и Использование BSD-сокетов в различных языках программирования. Он имеет опыт разработки процессоров для геостационарных космических летательных аппаратов, а также разработки архитектуры встраиваемых систем и сетевых протоколов. Сейчас Тим работает инженером-консультантом в корпорации Эмулекс (Emulex Corp.) в г.Лонгмонт, Колорадо.



01.07.2008

Протокол SCTP представляет собой надежный универсальный протокол транспортного уровня для сетей IP. Несмотря на то, что протокол изначально разрабатывался для передачи телефонных сигналов (RFC 2960), SCTP имеет дополнительные преимущества − он лишен некоторых ограничений протокола TCP, обладая при этом возможностями протокола UDP. Протокол SCTP предоставляет возможности, обеспечивающие высокую доступность, повышенную надежность и улучшенную безопасность сокетов. На рисунке 1 показана многоуровневая архитектура стека IP.

Рисунок 1. Многоуровневая архитектура стека IP
Многоуровневая архитектура стека IP

В этой статье дается общее представление о протоколе SCTP в ядре Linux 2.6, подчеркиваются его расширенные функциональные возможности (такие как множественная адресация и многопоточность), а также содержатся фрагменты (со ссылкой на полную версию) исходного текста программ клиента и сервера для демонстрации возможностей готовности и многопоточности.

Начнем с обзора стека протокола IP.

Стек протокола IP.

Набор протоколов Internet разделяется на несколько уровней; каждый уровень предоставляет определенный набор функциональных возможностей (см. рисунок 1).

Рассмотрим уровни стека протокола IP, начиная с нижнего:

  • Канальный уровень предоставляет физический интерфейс к среде передачи (например, Ethernet).
  • Сетевой уровень управляет передачей пакетов по сети, обеспечивая их доставку получателю (этот процесс называют маршрутизацией).
  • Транспортный уровень обеспечивает управление потоком пакетов между двумя хостами в интересах прикладного уровня. Он также предоставляет приложению конечную точку взаимодействия, называемую портом.
  • Наконец, прикладной уровень обеспечивает представление данных, передаваемых через сокет. Эти данные могут, например, состоять из сообщений электронной почты, передаваемых по протоколу SMTP, или Web-страниц, передаваемых по протоколу HTTP.

В качестве интерфейса к протоколу транспортного уровня все протоколы прикладного уровня используют уровень сокетов. Интерфейс Sockets API был разработан для операционной системы UNIX® ® Калифорнийским университетом в Беркли (UC Berkeley).

Перед рассмотрением функционирования протокола SCTP вспомним, как работают традиционные протоколы транспортного уровня.

Протоколы транспортного уровня.

Двумя наиболее популярными протоколами транспортного уровня являются протоколы TCP и UDP:

  • Протокол TCP - это надежный протокол, который гарантирует последовательную упорядоченную передачу данных и обеспечивает управление нагрузкой в сети.
  • Протокол UDP, ориентированный на работу с сообщениями, не предоставляет никаких гарантий ни по очередности доставки сообщений, ни по контролю перегрузки.

Тем не менее UDP является быстрым протоколом и обеспечивает сохранение границ сообщений.

В этой статье рассматривается альтернативный протокол SCTP. Он обеспечивает надежную упорядоченную передачу данных подобно протоколу TCP, но ориентирован на передачу сообщений подобно протоколу UDP. Кроме того, протокол SCTP предоставляет дополнительные возможности:

  • множественная адресация;
  • многопотоковая передача данных;
  • безопасность устанавливаемого подключения;
  • формирование кадров сообщений;
  • настраиваемая неупорядоченная передача данных;
  • поэтапное завершение работы.

Основные особенности SCTP:

По сравнению с традиционными транспортными протоколами наиболее значительные улучшения в протоколе SCTP состоят в поддержке множественной адресации конечных хостов и многопотоковой передачи данных.

Множественная адресация

По сравнению с протоколом TCP поддержка протоколом SCTP множественной адресации обеспечивает приложениям повышенную готовность. Хост, подключенный к нескольким сетевым интерфейсам и потому имеющий несколько IP адресов, называется multi-homed хост. В протоколе TCP соединением называется канал между двумя конечными точками (в данном случае сокет между интерфейсами двух хостов). Протокол SCTP вводит понятие ассоциации, которая устанавливается между двумя хостами и в рамках которой возможна организация взаимодействия между несколькими интерфейсами каждого хоста.

На рисунке 2 показано отличие соединения протокола TCP и ассоциации протокола SCTP.

Рисунок 2. Отличие между соединением протокола TCP и ассоциацией протокола SCTP
Отличие между соединением протокола TCP и ассоциацией протокола SCTP

В верхней части рисунка показано соединение протокола TCP. Каждый хост имеет один сетевой интерфейс, соединение устанавливается между одним интерфейсом на клиенте и одним интерфейсом на сервере. Установленное соединение привязано к конкретному интерфейсу.

В нижней части рисунка представлена архитектура, в которой каждый хост имеет два сетевых интерфейса. Обеспечивается два маршрута по независимым сетям: один от интерфейса C0 к интерфейсу S0, другой — от интерфейса C1 к интерфейсу S1. В протоколе SCTP два этих маршрута объединяются в ассоциацию.

Протокол SCTP отслеживает состояние маршрутов в ассоциации с помощью встроенного механизма контрольных сообщений; при нарушении маршрута передача данных продолжается по альтернативному маршруту. При этом приложению даже не обязательно знать о фактах нарушения и восстановления маршрута.

Переключение на резервный канал также может обеспечивать непрерывность связи для сетевых приложений. Для примера рассмотрим ноутбук, который имеет беспроводный интерфейс 802.11 и интерфейс Ethernet. Пока ноутбук подключен к док-станции, предпочтительнее использовать более скоростной интерфейс Ethernet (в протоколе SCTP используется термин основной адрес); при нарушении этого соединения (в случае отключения от док-станции), будет использоваться соединение по беспроводному интерфейсу. При повторном подключении к док-станции будет обнаружено соединение по интерфейсу Ethernet, через который будет продолжен обмен данными. Таким образом, протокол SCTP реализует эффективный механизм, обеспечивающий высокую готовность и повышенную надежность.

Многопотоковая передача данных

В некоторой степени ассоциация протокола SCTP похожа на соединение протокола TCP. Отличие состоит в том, что протокол SCTP поддерживает несколько потоков в рамках одной ассоциации. Все потоки являются независимыми, но принадлежат одной ассоциации (см. рисунок 3).

Рисунок 3. Взаимосвязь между ассоциацией протокола SCTP и потоками.
Взаимосвязь между ассоциацией протокола SCTP и потоками.

Каждому потоку ассоциации присваивается номер, который включается в передающиеся пакеты SCTP. Важность многопотоковой передачи обусловлена тем, что блокировка какого-либо потока (например, из-за ожидания повторной передачи при потере пакета) не оказывает влияния на другие потоки в ассоциации. В общем случае данная проблема получила название блокировка головы очереди (head-of-line blocking). Протокол TCP уязвим для подобных блокировок.

Каким образом множество потоков обеспечивают лучшую оперативность при передаче данных? Например, в протоколе HTTP данные и служебная информация передаются по одному и тому же сокету. Web-клиент запрашивает файл, и сервер посылает файл назад к клиенту по тому же самому соединению. Многопотоковый HTTP-сервер сможет обеспечить более быструю передачу, так как множество запросов может обслуживаться по независимым потокам одной ассоциации. Такая возможность позволяет распараллелить ответы сервера. Это если и не повысит скорость отображения страницы, то позволит обеспечить ее лучшее восприятие благодаря одновременной загрузке кода HTML и графических изображений.

Многопотоковая передача − это важнейшая особенность протокола SCTP, особенно в том, что касается одновременной передачи данных и служебной информации в рамках протокола. В протоколе TCP данные и служебная информация передаются по одному соединению. Это может стать причиной проблем, так как служебные пакеты из-за передачи данных будут передаваться с задержкой. Если служебные пакеты и пакеты данных передаются по независимым потокам, то служебная информация будет обрабатываться своевременно, что, в свою очередь, приведет к лучшему использованию доступных ресурсов.

Безопасность устанавливаемого подключения

Создание нового подключения в протоколах TCP и SCTP происходит при помощи механизма подтверждения (квитирования) пакетов. В протоколе TCP данная процедура получила название трехэтапное квитирование (three-way handshake). Клиент посылает пакет SYN (сокр. Synchronize). Сервер отвечает пакетом SYN-ACK (Synchronize-Acknowledge). Клиент подтверждает прием пакета SYN-ACK пакетом ACK. На этом процедура установления соединения (показана на рисунке 4) завершается.

Рисунок 4. Обмен пакетами при установлении соединения по протоколам TCP и SCTP
Обмен пакетами при установлении соединения по протоколам TCP и SCTP

Протокол TCP имеет потенциальную уязвимость, обусловленную тем, что нарушитель, установив фальшивый IP-адрес отправителя, может послать серверу множество пакетов SYN. При получении пакета SYN сервер выделяет часть своих ресурсов для установления нового соединения. Обработка множества пакетов SYN рано или поздно, затребует все ресурсы сервера и сделает невозможным обработку новых запросов Такая атака получила название «отказ в обслуживании» ( Denial of Service (DoS)).

Протокол SCTP защищен от подобных атак с помощью механизма четырехэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.

Для решения проблемы задержки пересылки данных при выполнении процедуры четырехэтапного квитирования в протоколе SCTP допускается включение данных в пакеты COOKIE-ECHO и COOKIE-ACK.

Формирование кадров сообщения

При формировании кадров сообщения обеспечивается сохранение границ сообщения в том виде, в котором оно передается сокету; это означает, что если клиент посылает серверу 100 байт, за которыми следуют 50 байт, то сервер воспринимает 100 байт и 50 байт за две операции чтения. Точно так же функционирует протокол UDP, это является особенностью протоколов, ориентированных на работу с сообщениями.

В противоположность им протокол TCP обрабатывает неструктурированный поток байт. Если не использовать процедуру формирования кадров сообщения, то узел сети может получать данные по размеру больше или меньше отправленных. Такой режим функционирования требует, чтобы для протоколов, ориентированных на работу с сообщениями и функционирующих поверх протокола TCP, на прикладном уровне был предоставлен специальный буфер данных и выполнялась процедура формирования кадров сообщений (что потенциально является сложной задачей).

Протокол SCTP обеспечивает формирование кадров при передаче данных. Когда узел выполняет запись в сокет, его корреспондент с гарантией получает блок данных того же размера (см. рисунок 5).

Рисунок 5. Формирование кадров сообщений по протоколу UDP/SCTP и по протоколу, обрабатывающему неструктурированный поток байт
Формирование кадров сообщений по протоколу UDP/SCTP и по протоколу, обрабатывающему неструктурированный поток байт

При передаче потоковых данных (аудио- и видеоданных) процедура формирования кадров необязательна.

Настраиваемая неупорядоченная передача данных

Сообщения по протоколу SCTP передаются с высокой степенью надежности, но необязательно в нужном порядке. Протокол TCP гарантирует, что данные будут получены именно в том порядке, в котором они отправлялись (это хорошо, учитывая, что TCP – это потоковый протокол). Протокол UDP не гарантирует упорядоченную доставку. При необходимости вы можете настроить потоки в протоколе SCTP так, чтобы они принимали неупорядоченные сообщения.

Эта особенность может быть востребована в протоколах, ориентированных на работу с сообщениями, так как запросы в них независимы и последовательность поступления данных не очень важна. Кроме того, вы можете настроить использование неупорядоченной передачи по номеру потока в ассоциации, т.е. принимая сообщения по потокам.

Поэтапное завершение передачи данных

В отличие от протокола UDP, функционирование которого не предполагает установления соединения, протоколы TCP и SCTP являются протоколами с установлением соединения. Оба эти протокола требуют выполнения процедуры установления и разрыва соединения между корреспондентами. Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.

На рисунке 6 показана последовательность разрыва соединения в протоколах TCP и SCTP.

Рисунок 6. Последовательность разрыва соединения по протоколам TCP и SCTP
Последовательность разрыва соединения по протоколам TCP и SCTP

В протоколе TCP возможна ситуация, когда узел закрывает у себя сокет (выполняя посылку пакета FIN), но продолжает принимать данные. Пакет FIN указывает корреспонденту на отсутствие данных для передачи, однако до тех пор, пока корреспондент не закроет свой сокет, он может продолжать передавать данные. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.

Пример реализации многопотоковой передачи

Теперь, когда вам известны основные возможности протокола SCTP, рассмотрим пример реализации серверного и клиентского приложений. Исходный текст программы написан на языке программирования C и демонстрирует возможности протокола SCTP по многопотоковой передаче данных.

В этом примере сервер реализует одну из форм протокола точного времени, сообщая текущее время подключенному клиенту. Однако для демонстрации возможностей протокола SCTP, я передаю местное время по потоку 0 и время по Гринвичу (GMT) в потоке 1. Этот простой пример позволяет продемонстрировать интерфейс API потокового взаимодействия.

На рисунке 7 демонстрируется весь процесс взаимодействия: показан не только поток данных приложения по API сокетов, но и взаимосвязи между клиентом и сервером.

Рисунок 7. Функции сокетов, используемые при многопотоковой реализации сервера и клиента точного времени
Функции сокетов, используемые при многопотоковой реализации сервера и клиента точного времени

Серверное и клиентское приложения были разработаны в операционной системе GNU/Linux с ядром 2.6.11 пакетом проекта Linux Kernel SCTP (lksctp). В пакете lksctp, доступном на SourceForge, реализованы нестандартные функции сокетов. Более подробные сведения об этом компоненте можно найти в разделе Ресурсы.

Сервер точного времени

Исходный код приложения многопоточного сервера точного времени показан в листинге 1. Для удобства чтения в листинг 1 не включен код контроля ошибок, однако по ссылке ниже вы можете загрузить полный исходный текст программы, включающий функции контроля ошибок и другие расширения сокетов протокола SCTP.

Листинг 1. Сервер точного времени для протокола SCTP, использующий многопотоковую передачу.
int main()
{
  int listenSock, connSock, ret;
  struct sockaddr_in servaddr;
  char buffer[MAX_BUFFER+1];
  time_t currentTime;

  /* Создание сокета SCTP в стиле TCP */
  listenSock = socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );

  /* Принимается соединение с любого интерфейса */
  bzero( (void *)&servaddr, sizeof(servaddr) );
  servaddr.sin_family = AF_INET;
  servaddr.sin_addr.s_addr = htonl( INADDR_ANY );
  servaddr.sin_port = htons(MY_PORT_NUM);

  /* Адрес привязки – любой, порт - MY_PORT_NUM */
  ret = bind( listenSock,
               (struct sockaddr *)&servaddr, sizeof(servaddr) );

  /* Сокет сервера переводится в состояние ожидания соединения */
  listen( listenSock, 5 );

  /* Цикл работы сервера... */
  while( 1 ) {

    /* Ожидание соединения клиента */
    connSock = accept( listenSock,
                        (struct sockaddr *)NULL, (int *)NULL );

    /* Соединение с новым клиентом */

    /* Выясняется текущее время */
    currentTime = time(NULL);

    /* Посылается текущее время по потоку 0 (поток для локального времени) */
    snprintf( buffer, MAX_BUFFER, "%s\n", ctime(&currentTime) );

    ret = sctp_sendmsg( connSock,
                          (void *)buffer, (size_t)strlen(buffer),
                          NULL, 0, 0, 0, LOCALTIME_STREAM, 0, 0 );

    /* Посылается GMT по потоку 1 (поток для GMT) */
    snprintf( buffer, MAX_BUFFER, "%s\n",
               asctime( gmtime( &currentTime ) ) );

    ret = sctp_sendmsg( connSock,
                          (void *)buffer, (size_t)strlen(buffer),
                          NULL, 0, 0, 0, GMT_STREAM, 0, 0 );

    /* Закрывается клиентское соединение */
    close( connSock );

  }

  return 0;
}

Исходный код в листинге 1 начинается с создания сокета сервера (IPPROTO_SCTP используется для создания сокета SCTP прямого соединения). Затем создается структура sockaddr, в которой указывается, что разрешаются соединения к любому локальному интерфейсу (используется подстановочный (wildcard) адрес INADDR_ANY). Структура sockaddr привязывается к сокету с помощью вызова bind, а потом сокет сервера переводится в состояние прослушивания (listening state). С этого момента возможны входящие соединения.

Обратите внимание на то, что протокол SCTP использует многие из тех же сокетов API, что и протоколы TCP и UDP. Некоторые дополнительные функции API реализованы в инструментах разработки lksctp (см. раздел Ресурсы).

Серверная программа ожидает в цикле нового подключения клиента. При возвращении из функции accept создается новое клиентское подключение, определяемое сокетом connSock. С помощью функции time выясняется текущее время и переводится в строку функцией snprintf. С помощью функции sctp_sendmsg (нестандартный вызов сокета) строка посылается клиенту по заданному потоку (LOCALTIME_STREAM). После того как строка с локальным временем послана, текущее время переводится в формат GMT и посылается по потоку GMT_STREAM.

Таким образом, сервер выполнил свои функции, поэтому сокет закрывается и переходит в режим ожидания нового клиентского подключения. Просто, не так ли? Теперь рассмотрим, как клиент протокола точного времени обрабатывает многопотоковую передачу.

Клиент протокола точного времени

Реализация многопоточного клиента приводится в листинге 2.

Листинг 2. Реализация клиента точного времени для протокола SCTP, использующего многопотоковую передачу.
int main()
{
  int connSock, in, i, flags;
  struct sockaddr_in servaddr;
  struct sctp_sndrcvinfo sndrcvinfo;
  struct sctp_event_subscribe events;
  char buffer[MAX_BUFFER+1];

  /* Создание сокета SCTP в стиле TCP */
  connSock = socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );

  /* Определяется адрес точки соединения */
  bzero( (void *)&servaddr, sizeof(servaddr) );
  servaddr.sin_family = AF_INET;
  servaddr.sin_port = htons(MY_PORT_NUM);
  servaddr.sin_addr.s_addr = inet_addr( "127.0.0.1" );

  /* Соединение с сервером */
  connect( connSock, (struct sockaddr *)&servaddr, sizeof(servaddr) );

  /* Ожидается получение данных SCTP Snd/Rcv с помощью функции sctp_recvmsg */
  memset( (void *)&events, 0, sizeof(events) );
  events.sctp_data_io_event = 1;
  setsockopt( connSock, SOL_SCTP, SCTP_EVENTS,
               (const void *)&events, sizeof(events) );

  /* Ожидается получение двух сообщений */
  for (i = 0 ; i < 2 ; i++) {

    in = sctp_recvmsg( connSock, (void *)buffer, sizeof(buffer),
                        (struct sockaddr *)NULL, 0,
                        &sndrcvinfo, &flags );

    /* Завершающий символ строки – 0 */
    buffer[in] = 0;

    if        (sndrcvinfo.sinfo_stream == LOCALTIME_STREAM) {
      printf("(Local) %s\n", buffer);
    } else if (sndrcvinfo.sinfo_stream == GMT_STREAM) {
      printf("(GMT  ) %s\n", buffer);
    }

  }

  /* Закрытие сокета и выход */
  close(connSock);

  return 0;
}

В клиентском приложении создается сокет протокола SCTP, а затем структура sockaddr, содержащая информацию о конечной точке подключения. После этого с помощью функции connect устанавливается соединение с сервером. Для того чтобы получить номер потока сообщений по протоколу SCTP, необходимо указать параметр сокета sctp_data_io_event.

При получении сообщения с помощью функции API sctp_recvmsg дополнительно принимается структура sctp_sndrcvinfo, содержащая номер потока. Этот номер позволяет различать сообщения потока 0 (местное время) и потока 1 (GMT).

Будущее протокола SCTP.

Протокол SCTP является сравнительно новым протоколом, учитывая то, что он был представлен в виде RFC в октябре 2000 года. С этого момента он начал использоваться во многих операционных системах, включая GNU/Linux, BSD и Solaris. В виде дополнительного коммерческого пакета независимого поставщика он также доступен для операционной системы Microsoft® Windows®.

По мере расширения доступности протокола SCTP его будут использовать в качестве основного транспортного протокола все новые приложения. На базе SCTP уже созданы такие традиционные приложения, как FTP и HTTP. Протокол SCTP также используется и в других протоколах, например, протоколе установления сессии (Session Initiation Protocol (SIP)) и протоколе канальной сигнализации № 7 (Common Channel Signaling System No7 (SS7)). Коммерческую реализацию протокола SCTP имеет операционная система Cisco IOS.

После включения протокола SCTP в ядро Linux 2.6 стало возможным построение и развертывание надежных сетевых приложений высокой готовности. Основываясь на протоколе IP, SCTP позволяет прозрачно заменить протоколы TCP и UDP, введя при этом дополнительные возможности: множественную адресацию, многопоточную передачу и повышенную безопасность. Сейчас, когда вы познакомились с некоторыми преимуществами протокола SCTP, вы можете исследовать другие его возможности. В проекте Linux Kernel SCTP (lksctp) имеются документация и дополнительные функции API, которые помогут вам в ваших исследованиях.


Загрузка

ОписаниеИмяРазмер
Multi-streaming demo source codel-sctp-msdemo.zip74KB

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=317661
ArticleTitle=Надежная передача данных по протоколу SCTP
publish-date=07012008