Посыпаю голову пеплом.

Ошибку я нашёл. В коде написанном два года назад под Линукс. И нареканий до сих пор не вызывавшем.

Последний месяц всё больше ненавижу винду. А сегодня вечером особенно свою невнимательность.

Вы, надеюсь, хотябы поняли, что в ТСР нет понятия "пакет" ?
А то блин... Маразм-то крепчает, от нас сейчас госструктура одна требует отправки сообщений некоего протокола "целым кол-вом штук в одном ТСР-пакете и чтоб пакет с начала сообщения начинался". Доводы и убеждения на них не действуют. "Хотим и всё". Приходится через задницу всё делать...

MC>Опять "пакеты" в TCP...
MC>Я устал. RTFM.

imho, вопрос именования TCP сегментов пакетами не является таким уж принципиальным. Действительно, ранние RFC не использовали понятия packet применительно к TCP.

Вот что по этому поводу есть в Wikipedia:
http://en.wikipedia.org/wiki/TCP_segment

Transmission Control Protocol (TCP) accepts data from a data stream, 'segments' it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated, into an IP datagram. A TCP segment is "the packet of information that TCP uses to exchange data with its peers." [1]

Note that the term TCP packet is now used interchangably with the term TCP segment. [2][3] Although in the original RFC segment usually referred to the TCP unit of data, datagram[4] to the IP unit and packet to the data communications network unit:

Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module [e.g. IP] to transmit each segment to the destination TCP.[5]

Так что если назвать TCP сегмент пакетом искажения смысла не произойдет. Конечно же все дело в том как именно формируются эти самые сегменты (или пакеты).

Здравствуйте, AlexCrush, Вы писали:

AC>Вы, надеюсь, хотябы поняли, что в ТСР нет понятия "пакет" ?
AC>А то блин... Маразм-то крепчает, от нас сейчас госструктура одна требует отправки сообщений некоего протокола "целым кол-вом штук в одном ТСР-пакете и чтоб пакет с начала сообщения начинался". Доводы и убеждения на них не действуют. "Хотим и всё". Приходится через задницу всё делать...
А как они намерены это проверять?

Здравствуйте, Аноним, Вы писали:

А>Так что если назвать TCP сегмент пакетом искажения смысла не произойдет.

В том-то и дело что происходит искажение смысла. Под "пакетом" люди чаще всего понимают то что получается за один вызов recv/recvfrom (лично я ни разу не видел на этом форуме другого толкования от людей, пишущих про пакеты в TCP). А сегменты TCP до такого уровня просто не доживают! Теоретически нет никакой связи между тем, сколько данных ты получаешь за один вызов recv и тем, каков размер сегмента TCP в данный момент. И даже с тем, какими порциями отправлял send на другой стороне. Поэтому все предположения и выводы насчет пакетов в TCP неверны в корне.

Здравствуйте, Garrett, Вы писали:

AC>>А то блин... Маразм-то крепчает, от нас сейчас госструктура одна требует отправки сообщений некоего протокола "целым кол-вом штук в одном ТСР-пакете и чтоб пакет с начала сообщения начинался". Доводы и убеждения на них не действуют. "Хотим и всё". Приходится через задницу всё делать...
G>А как они намерены это проверять?

Снифером, наверное. С подменой понятия "сегмент TCP" на "пакет TCP"
Проверяется-то элементарно. Сама постановка задачи, конечно, идиотская. Не могу даже представить, чем может быть вызвана. И, если уж есть какие-то веские причины, то причем тут TCP? Реализовывали бы уже на UDP или писали бы свой транспортный протокол.

Здравствуйте, Michael Chelnokov, Вы писали:

G>>А как они намерены это проверять?

MC>Снифером, наверное. С подменой понятия "сегмент TCP" на "пакет TCP"
MC>Проверяется-то элементарно. Сама постановка задачи, конечно, идиотская. Не могу даже представить, чем может быть вызвана. И, если уж есть какие-то веские причины, то причем тут TCP? Реализовывали бы уже на UDP или писали бы свой транспортный протокол.
Я к тому, что может никто и проверять-то не будет? Раз они сами не знают зачем им это надо ("Хотим и все!")

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Здравствуйте, Аноним, Вы писали:

А>>Так что если назвать TCP сегмент пакетом искажения смысла не произойдет.

MC>В том-то и дело что происходит искажение смысла. Под "пакетом" люди чаще всего понимают то что получается за один вызов recv/recvfrom
(лично я ни разу не видел на этом форуме другого толкования от людей, пишущих про пакеты в TCP).

Пакетом называется последовательность байт, имеющая определенную структуру — заголовок( данные управляющие передачей ) и данные пользователя (payload).
Пакет — единица передачи данных по сети. Определение пакета не имеет никакого отношения к функциям recv, recvfrom. Также, определение пакета никак не связано c Вашим пониманием "толкования от людей, пишущих про пакеты в TCP" на данном форуме. Пакет это не то что получается за один вызов recv. recv получает данные(набор байт) из сокета. В этом наборе нет никакого заголовка. А вот recvfrom получает даже не пакет, а датаграмму. Опять пользователю возвращаются лишь сами данные и адрес источника.

Посмотрите на использование термина packet применительно к TCP за пределами форума в сети и вы увидите что термин packet также широко используется. При этом никакой неоднозначности не возникает.

MC>>Снифером, наверное. С подменой понятия "сегмент TCP" на "пакет TCP"
MC>>Проверяется-то элементарно. Сама постановка задачи, конечно, идиотская. Не могу даже представить, чем может быть вызвана. И, если уж есть какие-то веские причины, то причем тут TCP? Реализовывали бы уже на UDP или писали бы свой транспортный протокол.
G>Я к тому, что может никто и проверять-то не будет? Раз они сами не знают зачем им это надо ("Хотим и все!")

Ох, жжоте, ой как жжоте, граждане, муахахахахаха..............................
Чуть из кресла не вывалился от смеха.

А вообще грустно это всё, конечно.

Здравствуйте, Unmanaged, Вы писали:

U>Ох, жжоте, ой как жжоте, граждане, муахахахахаха..............................
U>Чуть из кресла не вывалился от смеха.
U>А вообще грустно это всё, конечно.

Это специфика работы с госструктурами.

AC>А то блин... Маразм-то крепчает, от нас сейчас госструктура одна требует отправки сообщений некоего протокола "целым кол-вом штук в одном ТСР-пакете и чтоб пакет с начала сообщения начинался". Доводы и убеждения на них не действуют. "Хотим и всё". Приходится через задницу всё делать...

Пересылайте через UDP. А в начале пакете в ASCII кодировке напишите: "ТСР пакет, ГОСТ 793-81"

Всё гораздо хуже. Проверять они это будут 1) сниффером 2) своим кривым приложением.
если в 1м случае мы еще кое-как можем сделать так чтобы пакеты действительно содержали только целые сообщения (хотя и это сверхгеморрой, учитывая что нам это нужно аж под 3мя ОС: pSOS, VxWorks, Linux), то во втором случае засада полная.

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

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

Сейчас эта самая госструктура собирается вносить данное требование по ТСР-пакетам в официальные тех-условия на протокол. Не ту страну назвали гондурасом...


З.Ы. предлагаю соревновательный конкурс-задачку: как реализовать управление пакетами в рамках стандартного сокетного API.(З.Ы. у нас кое-как, но работает).

AC>З.Ы. предлагаю соревновательный конкурс-задачку: как реализовать управление пакетами в рамках стандартного сокетного API.(З.Ы. у нас кое-как, но работает).

Чо тут думать то? Открываем сырой сокет, лепим пакеты вручную. Работать будет криво, зато проконтроллировать, что данные попадают в пакет целиком элементарно .

Здравствуйте, AlexCrush, Вы писали:

AC>pSOS, VxWorks, Linux
...
AC>есть у них кривое приложение

Оно тоже многоплатформенное?

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Оно тоже многоплатформенное?

Не, у них кажись Sun Solaris.

Здравствуйте, TarasCo, Вы писали:

TC>Чо тут думать то? Открываем сырой сокет, лепим пакеты вручную. Работать будет криво, зато проконтроллировать, что данные попадают в пакет целиком элементарно .

Под линуксом будет, ага. А pSOS с VxWorks? Фиг там а не raw сокеты, насколько я знаю.

AC>З.Ы. предлагаю соревновательный конкурс-задачку: как реализовать управление пакетами в рамках стандартного сокетного API.(З.Ы. у нас кое-как, но работает).

1. Контролировать чтобы уходящие данные были не слишком большого размера, и посылать их за 1 send
2. Посылать следующий не раньше чем через некоторое время, скажем, 1с.
3. Возможно, TCP_NODELAY включить.
Надежног не будет, но повышается вероятность что будет работать именно так.

Как вариант — ставить у товарищей спец-ретранслятор данных, слать все к нему, а он будет разбивать данные на порции если это необходимо и отправлять порциями на этот сервис локальной машины. Желательно с учетем пп1-2.

"кое-как", но работать будет.