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

Mahagam (16.01.2014 14:48, просмотров: 138) ответил Ralex на Смотрите что происходит

а. ясно. так как у нас предполагается работа только с виндой, и только с узким количеством "допущенных" до железки компов, то мы поступили проще: в реестр можно внести пару строчек, перезапустить сетевую карту и вуаля - винда начинает отвечать ацком на каждый пакет. и именно в таком режиме и получены мои мегабайты в секунду. сей метод, кстати, народ активно использует для уменьшения отклика в сетевых играх. а вот на надстройку над Nuttx было бы интересно посмотреть, и посмотреть как её можно прикрутить к uIP. потому как я предполагаю, что эти отложенные ацки дадут мне вообще все 100 мегабит потока от uIP (на данный момент у меня uIP жрет не более 18% процессора при максимальной скорости передачи)

Ответить

- Трэш, угар и содомия. - fk0(17.01.2014 00:16)
- Про пару строчек в реестре можно поподробнее? - MBedder(16.01.2014 15:31)
  - вот что нарыл сходу: Mahagam(837 знак., 16.01.2014 15:41)
    - Ага, спасибо, поковыряюсь - MBedder(16.01.2014 15:59)
- Тут Ralex(199 знак., 16.01.2014 15:10)
  - я поковырял текстовое описание этой надстройки. Mahagam(591 знак., 16.01.2014 15:32)
    - В каждом пакете с 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)

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