caxapa.ru :: я поковырял текстовое описание этой надстройки.

Mahagam (16.01.2014 15:32, просмотров: 169) ответил Ralex на Тут

я поковырял текстовое описание этой надстройки. она там типа лупит весь буфер сразу, а потом ждёт ацков. и возвращается только если все ацки пришли. там логично описывают, что если буфер порвали на чётное число пакетов, то возращается сразу как всё подтвердилось, а если нечётное - то на последний пакет ждёмс 200ms. но у меня сразу возник вопрос, а если что-то недошло? если ацк на пакет из середины обломался? как это будет работать? хотя наверное это уже учтено. надо в коде ковыряться. мне такое не подойдёт вообще. у меня из одного кольцевого буфера данные выгребать могут много соединений, как тут send() организовать я не знаю

Ответить

- В каждом пакете с ACK (см. в википедии описание TCP протокола) говорится какой номер пакета подтверждается. Если пакет подтверждается -- значит он и все более ранние пакеты уже приняты ( fk0(802 знак., 17.01.2014 00:40)
  - ну так логично. uIP точилась под системы без нормальных объёмов памяти. если ей наделать окон да буферов, буквочку "u" перед IP придётся убрать. и получится lwIP. - Mahagam(17.01.2014 00:44)
    - Если система без нормальных объёмов памяти (пик контроллер проф. уровня) передаёт из файла, то окно может быть большим, если в файле можно делать seek()... Просто интерфейс сокетов этого не предусматривает. Например, при чтении из flash памяти. - fk0(17.01.2014 10:05)
    - Логично. Но как же тогда телнет работает? Там ничего не тормозит. TCP_NODELAY? Может uIP не ставит этот бит? - fk0(17.01.2014 00:52)
      - uIP ставит в каждом пакете бит ACK, и кроме того, принудительно ставит бит PUSH, по которому стек должен пропихнуть данные приложению - Mahagam(17.01.2014 10:12)
      - TCP_NODELAY отключает алгоритм Нейгла, и влияет только на сборку мелких кусочков в один пакет, то есть - на передающую сторону. У нас проблема в приемной стороне - она считает ворон 200мс. Если вы пишете на клавиатуре, то с TCP_NODELAY у вас не Ralex(276 знак., 17.01.2014 03:46)
        
        См. rfc2581, раздел 4.2. "Out-of-order data segments SHOULD be acknowledged immediately..." -- возможно, это решение. - fk0(17.01.2014 10:00)
- Угу, знакомая ситуация. Мой вин-программист не знает, как организовать выгребание данных из одного порта приходящего UDP-потока одновременно несколькими процессами. Пока костыльно извратились посредством посылания дублирующего потока в другой MBedder(47 знак., 16.01.2014 16:04)
  - SO_REUSEADDR и multicast UDP (через IGMP) - Nick(16.01.2014 21:51, )
    - +1 всё реально. Но девайс сразу в IGMP вещать должен. Тогда закат солнца вручную не нужен. - fk0(17.01.2014 00:16)
  - то есть про кольцевой буфер он не знает? ) Mahagam(86 знак., 16.01.2014 16:24)
    - Чтобы учинить кольцевой буфер в винде, нужно в драйверный уровень погрузиться, а это он не умеет :( - MBedder(16.01.2014 16:56)
      - Это ты не знаешь, что любой fifo, unix domain socket или tcp socket дадут тот самый буфер. 4кб, 128кб и 128кб соответственно (типично). Собственно если железяка IGMP не может, то можно сделать повторитель вещающий в IGMP, а от него уже и принимать fk0(525 знак., 17.01.2014 00:21 - 00:42)
        
        У меня железка создает UDP-поток, и IGMP сделать - не проблема. Конфигурация примитивная - точка-точка, без посторонних источников и хабов/свитчей, т.е. сети как таковой нету - MBedder(17.01.2014 00:44)
      - так в своём софте. а дальше раздавать процессам данные уже из этого буфера. - Mahagam(16.01.2014 17:05)
        
        На уровне ОС это недоступно ИМХО - MBedder(16.01.2014 17:07)
  - А для чего такой изврат нужен - "одновременно несколькими процессами"? Даже если нужен, то это твой программист вполне логично делает. Порт открывается на прослушивание только в одином процессе. Правда может разумнее не пулять в остальные процессы Гудвин(47 знак., 16.01.2014 16:17)
    - Кстати да. Избежать лишнего копирования больших объёмов данных вообще. В одном процессе ручками таки сделать пресловутый буфер и расшарить память между всеми процессами. Как все дочитали (или как там нужно?) каждый пинает (через мессаги и т.п.) fk0(55 знак., 17.01.2014 00:24)
      - Фишка в том, что "главного" процесса кагбэ нету - есть отдельные самодостаточные приложения, которые могут запускаться независимо в нескольких экземплярах одновременно на одном компе - MBedder(17.01.2014 00:46)
        
        что-то мне напоминает старый добрый NetCat с "|" - Vit(17.01.2014 01:02)
        
        А поподробней можно? - MBedder(17.01.2014 02:44)
        
        оно прямоугольное. нюхает порт и когда услышит может поднять чего надо (например cmd - в виндовом nc ключик -e). ну и как обычно можно перенаправить поток нужной программе. Vit(256 знак., 17.01.2014 03:02, ссылка, ссылка)
        
        Поднять чего надо: это, скорей, inetd. - fk0(17.01.2014 09:55)
        
        А когда уже поднято? - MBedder(17.01.2014 11:18)

Средства и методы разработки