Передача пакетов по TCP/IP

Указание длинны пакета.

> длинны

оооох... тяжко мне

Длины :)

ASN.1

> Указание длинны пакета Годится, если не будет разрывов связи и потери части пакета.

TLV

В этом случае и символьно-шестнадцатеричные строки не спасут

sctp

> Годится, если не будет разрывов связи и потери части пакета.

TCP в пределах сессии гарантирует неразрывность следования пакетов. Разрыв сессии нужно обрабатывать в софте.

какой-нить готовый сериализатор или шину сообщений возьми.

> какой-нить готовый сериализатор или шину сообщений возьми.

Можно поподробнее, со ссылками. Я с этим не знаком

http://www.zeromq.org/

C UDP тоже никто не гарантирует, что отдельные датаграммы не слепятся вместе. Или я ошибаюсь?

C UDP тоже никто не гарантирует, что отдельные датаграммы не слепятся вместе. Или я ошибаюсь?

По-моему все-таки ошибаетесь :) Они могут потеряться, могут наоборот пройти несколько раз одна и та же, но вот слепиться вместе - нет. Равно как и прийти по кусочкам.

> C UDP тоже никто не гарантирует, что отдельные датаграммы не > > >слепятся вместе. Или я ошибаюсь?

Не думаю, что слепятся . Насколько я знаю, в UDP пакете присутствует контрольная сумма. Не гарантируется порядок доставки пакетов и пакеты могут потерятся-повторов нет.

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

Одно сообщение может быть разбито на несколько датаграмм, если оно больше их размера (который в стандарте не указан).

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

Ага. Только потом вдруг откуда ни возьмись всплывают юзера с криками 'Не работает ааа!'. Начинаешь выяснять - оказывается, ISPы блокируют все кроме UDP/TCP. И таких - масса. Вот радость то со всем этим потом разбираться..

Решение нашли еще в незапамятные времена. Если не хотите читать Стивенса, то вот эта книжка гораздо короче. Издавалась и на русском языке.

Effective TCP/IP Programming by Jon C. Snader

Эффективное программирование TCP,IP , Йон Снейдер

Посмотри http://www.zeroc.com/

Это рекомендует mv. Я, правда, не рискнул это внедрять ибо с одной стороны оверкилл для моих задач, с другой кое-чего там не было.

Фигасе, где это я ORB для транспорта рекомендовал? Автору тут нужен мессейджинг, типа уже озвученного zeromq. Правда, у первой версии немножко кривоват дизайн, а вторая ещё в глубокой альфе ;) Но впечатляет!

ice ты рекомендовал для мессаджинга.

На сколько я понял, именно это автору и нужно. Хотя, конечно, было бы лучше если бы топикстартер рассказал какая задача решается.

Не надо пролюбливать другим моск!

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

iu_int32_t size;
if (recv(sock,&size,sizeof(size),MSG_WAITALL)!=sizeof(size)) return ERROR_BROKEN_HEADER;
if (recv(sock,buffer,size,MSG_WAITALL)!=size) return ERROR_BROKEN_DATA;
return NO_ERROR;

Если тебе надо организовать гарантированную доставку сообщений, берешь соответствующий софт типа MQSeries, OpenMQ или еще что-нибудь из той же серии.

Все это гонится по TCP, после чего вся процедура обработки сводится к простому

iu_int32_t size;
if (recv(sock,&size,sizeof(size),MSG_WAITALL)!=sizeof(size)) return ERROR_BROKEN_HEADER;
if (recv(sock,buffer,size,MSG_WAITALL)!=size) return ERROR_BROKEN_DATA;
return NO_ERROR;

Хм... а разве TCP гарантирует, что данные придут сразу целиком? Допустим мы отправили 15кб данных, ведь не гарантируется же, что они так разом 15кб и придут, а не кусками по килобайту? Так что надо это всё завернуть в цикл, который будет «собирать» данные в пакеты, которые изначально были отправлены. Или я ошибаюсь?

Так что надо это всё завернуть в цикл, который будет «собирать» данные в пакеты, которые изначально были отправлены. Или я ошибаюсь?

Ошибаешься шопипец. Если бы ты написал более категорично, то я сказал бы, что сливаешь. А так просто ошибаешься

Приложению, открывшему TCP-сокет, становится абсолютно монопениссуально на порядок следования пакетов - такое соединение всего лишь ещё один поток данных, который можно (2)read и (2)write. Викать только по такому потоку нельзя. Если вдруг пакеты поменяются местами или один из пакетов задержится, то приложение почувствует это как задержку в получении данных. И всего лишь. А какие уже самопальные протоколы будут уже поверх TCP - это личное дело написавшего прикладуху.

> Ошибаешься шопипец. Если бы ты написал более категорично, то я сказал бы, что сливаешь. А так просто ошибаешься

[code]MSG_WAITALL Этот флаг просит подождать, пока не придет полное запрошенное количество данных. Однако, этот вызов все равно может вернуть меньше данных, чем было запрошено, если был пойман сигнал, произошла ошибка или разрыв соединения, или если начали поступать данные другого типа, не того, который был сначала.[/code]

fail.

> if (recv(sock,&size,sizeof(size),MSG_WAITALL)!=sizeof(size))
+ size = (iu_int32_t) ntohl((uint32_t)size);
> if (recv(sock,buffer,size,MSG_WAITALL)!=size)

Ошибаешься шопипец. Если бы ты написал более категорично, то я сказал бы, что сливаешь. А так просто ошибаешься

Приложению, открывшему TCP-сокет, становится абсолютно монопениссуально на порядок следования пакетов - такое соединение всего лишь ещё один поток данных, который можно (2)read и (2)write. Викать только по такому потоку нельзя. Если вдруг пакеты поменяются местами или один из пакетов задержится, то приложение почувствует это как задержку в получении данных. И всего лишь. А какие уже самопальные протоколы будут уже поверх TCP - это личное дело написавшего прикладуху.

Я не про это говорил. Я говорил про то, что если мы с одной стороны отправили 15к одним махом, то не гарантированно что на другой стороне эти 15к так же получат целым куском. А не кусками по одному килобайту. Данные ясен пень придут в том же порядке байт за байтом.