caxapa.ru :: Общий вопрос по TCP/IP: что делать с передачей данных при потере линка?

VVB (08.11.2012 11:33, просмотров: 38746)

Общий вопрос по TCP/IP: что делать с передачей данных при потере линка? Вариантов может быть несколько. Любой стек требует низкоуровневых функций вывода, привязанных к конкретному МАС. Т.к. я использую lwIP, то и поведу речь о нём. Речь идёт только о функции низкоуровневого вывода данных по ethernet, назовём её write_eth(). Наличие линка определяется в начале функции. Вариант 1: ничего-не-передавать, увеличить счётчик ошибок, возвратить управление. Разборки останутся стеку (если это TCP, то девайс будет ждать ACK, который гарантированно не придёт, потому что пакет не отправился, при отсутствии ACK в течение заданного времени будет сделано заданное число повторов передачи пакета, затем, предположительно, сетевое соединение TCP разорвётся; если это UDP то стек ничего не будет делать). Вариант 2: блокировать функцию write_eth() до момента появления линка. Минус: также будет блокироваться весь стек lwIP, потому что работа стека осуществляется в той же задаче (tcpip_thread), из которой и производится вызов write_eth(). Вариант 3: сразу разорвать моё сетевое соединение TCP (о котором write_eth ничего не знает) при его наличии Вариант 4: разорвать моё сетевое соединение TCP (о котором write_eth ничего не знает) при его наличии через некоторое время.

Ответить

- Напишу сюда, ибо тоже общий вопрос, стоит ли фрагментировать IP пакеты, с TCP сегментами? или лучше смотреть MTU и уменьшать MSS? - OlegPowerC(13.11.2012 12:31)
  - Педивикия говорит, что фрагментация IP вредна для TCP -> SciFi(22 знак., 13.11.2012 12:36, ссылка)
    - Изучал исходники. Драйвера и стеки тоже не любят фрагментации пакетов. - ++(13.11.2012 14:58)
      - В каком смысле не любят? Мат в комментариях? :-) - SciFi(13.11.2012 15:02)
        
        Драйвер e1000 данные без флага EOP (end of packet) выбрасывает. Если нужны длинные пакеты, пользуйте jumbo. ++(414 знак., 14.11.2012 09:12, ссылка)
        
        :-))) Только IP fragmentation здесь вообще ни при чём. SciFi(142 знак., 14.11.2012 09:47)
- Предположим следующее: вы получаете адрес по DHCP, и линк пропал потому что маршрутизатор/коммутатор был заменен. Из этого следует что: OlegPowerC(521 знак., 09.11.2012 10:54)
- Конкретно за вариант 3 людей сжигать нужно (винда и вываливающийся из роутера кабель, ага). Вариант 1-2 разумный. - fk0(08.11.2012 22:26)
  - Не правда, по крайней мере на Windows 7 у меня даже при смене точки доступа или вытыкании втыкании кабеля, SSH RDP и Telnet продолжают прозрачно работать - OlegPowerC(09.11.2012 10:42)
  - Еще со времен ЕС ЭВМ главным моментом тестирования было выдергивание кабеля :) - Vladimir Ljaschko(08.11.2012 23:09)
- Исходные тексты драйверов Linux. При потере линка выполняются все ф-ии, что в close(). ++(232 знак., 08.11.2012 18:38)
  - Жёстко. А что творится уровнем выше? Разрывает ли ядро линукс уже установленные ТСР соединения (и пользовательская программа получает информацию об ошибке)? - VVB(09.11.2012 06:52)
    - Драйвер говорит стеку close(); ++(67 знак., 13.11.2012 15:02)
    - Нет. - fk0(09.11.2012 09:10)
  - Линукс меж тем при выдёргивании кабеля из компа не требует повторного входа в домен и т.п. - fk0(08.11.2012 23:07)
- Непонятна неоднозначность - TCP или UDP. Нужно сразу определиться. - Vladimir Ljaschko(08.11.2012 12:58)
  - Будет управляющее TCP соединение и соединение для передачи данных (TCP или UDP, пока что у меня есть возможность выбрать какое). ТСР намного проще для прикладного ПО, задача передачи даных получается лаконичной и простой, в отличие от UDP. Так VVB(78 знак., 08.11.2012 13:16)
- Суть для прикладного ПО такая же как и для варианта1. Я его описал для сбора статистики. Благо LPC1768 имеет так называемую "continous read" для заданного регистра PHY, и мне достаточно за пару тактов прочитать содержимое регистра микроконтроллера VVB(31 знак., 08.11.2012 12:34)
- Вариант 0: вообще не смотреть на состояние линка. ИМХО, нужно выбрать самый простой вариант, если приложение позволяет, дабы не плодить сущности. SciFi(322 знак., 08.11.2012 12:19)
  - Кстати, пользуясь тем хорошим фактом, что Вы знакомы c lwIP (почему-то с ним мало работают, в России), хочу задать вопрос. VVB(460 знак., 08.11.2012 13:32)
    - Ещё вопросы по lwIP. VVB(2047 знак., 09.11.2012 11:17)
      - Хочу уточнить про netconn. VVB(1240 знак., 13.11.2012 10:12 - 10:22)
        
        Не получилось. Вызов netconn_recv() внутри моей callback приводит к останову работы стека (задача tcpip_thread блокируется, по понятным причинам: netconn_recv ждёт семафора, который должна взвести заблокированная tcpip_thread), хотя есть принятые VVB(40 знак., 13.11.2012 14:45)
        
        Придётся-таки писать промежуточный слой. Аналог tcpip_thread(). VVB(1078 знак., 14.11.2012 06:36 - 07:29)
        
        Насколько я понимаю, в Netconn API нет механизма оповещения. Поэтому только опросом netconn_recv(). Ещё можно установить таймаут на ожидание netconn_recv(). - SciFi(13.11.2012 10:21, ссылка)
        
        Я использую таймаут, для других целей. Мой вышестоящий пост я отредактировал, посмотрите, пожалуйста. - VVB(13.11.2012 10:23)
        
        Не знаю, у меня lwip без ОСи (NOSYS == 1). Помнится, было написано, что ВСЯ работа с lwip должна быть в ОДНОМ потоке. Возможно, в последних версиях добавили блокировки, но не факт. SciFi(130 знак., 13.11.2012 10:30 - 10:35, ссылка)
      - Зачем нужно два определения для задания "окна" TCP? Есть TCP_WND и TCP_SND_BUF. Смысл у обоих должен быть один и тот же. - VVB(09.11.2012 14:11)
        
        Уже какая-то вакханалия пошла. Почитайте ликбез по TCP, полистайте код lwip. Это очень простой вопрос. - SciFi(09.11.2012 14:16)
        
        Авторы lwIP могли бы и очевиднее написать: TCP_RCV_WND и TCP_SND_WND - VVB(09.11.2012 15:12)
        
        Ну так OpenSource же, напишите :-) - OlegPowerC(09.11.2012 16:32)
      - Ответы: SciFi(422 знак., 09.11.2012 13:42)
      - Когда разберетесь с окнами, поделитесь пожалуйста информацией - OlegPowerC(09.11.2012 13:29)
        
        Всё классно получается! VVB(625 знак., 09.11.2012 13:41)
        
        Жалко, что нет хорошей документации. Вот FreeRTOS тоже opensource, но какая классная документация!!! А от документации lwIP меня тошнит. - VVB(09.11.2012 13:44)
        
        вот только фриртос сам говно. - Mahagam(09.11.2012 14:08)
        
        Есть и плюсы, редко встречающиеся в других RTOS: VVB(433 знак., 09.11.2012 15:35)
        
        Зачем же вы себя так мучаете?! ;-) - SciFi(09.11.2012 13:48)
        
        "знал бы прикуп -- жил бы в Сочи". Этой просто мой первый стек. А я стараюсь досконально разобраться в программных продувктах для систем жизнеобеспечения. Заявленные возможности меня впечатлили, сейчас доделаю scatter-gather zero-copy TX DMA и VVB(184 знак., 09.11.2012 13:52)
        
        Какую систему жизнеобеспечения вы делаете? Просто чтобы быть в курсе, если моя жизнь будет от неё зависеть :-) SciFi(344 знак., 09.11.2012 14:14)
        
        У меня есть работающий пример, скачанный с сайта NXP. Там это учтено. Делаю аппараты ИВЛ, ethernet там будет только для вывода данных на ПК и ему позволяется вообще не работать, без влияния на функции жизнеобеспечения. - VVB(09.11.2012 14:22, ссылка)
        
        Ну на самом деле спорно, а если у компа был размер 800 а стал 500 и обратно уже не венулся? - OlegPowerC(09.11.2012 13:43)
        
        Не спорно. Если ПК не увеличивает окно, значит он не готов принимать данные. В таком случае пусть этот ПК идёт лесом. Данные нужно слать благодарным слушателям. - SciFi(09.11.2012 13:45)
        
        А разве это не означает что он готов принять данные, просто меньшее их количество за раз? ну если wnd конечно в больше 1 - OlegPowerC(09.11.2012 14:19)
        
        Имеется понятие "глупое окно". Приёмнику запрещается пересылать ACK с малым размером окна (меньше чем половина его буфера или меньше чем заявленный MSS передатчика при установке соединения). - VVB(09.11.2012 14:25)
        
        Это я знаю, но я думаю, реализация TCP/IP компьютера, предусматривает разрешение данной проблемы, и он врядли объявит окно меньше половины от начального - OlegPowerC(09.11.2012 16:39)
      - IP_FRAG не влияет на поведение lwIP при ответе от ПК с окном меньше чем у даных для передачи, стек впадает в ступор (при этом не разрывая соединение) и просто перестаёт передавать данные. Что делать? - VVB(09.11.2012 12:12 - 13:14)
      - Если следовать логике TCP то закрыть соединение можно либо отправив FIN либо RST. В случае с FIN, сокет по идее не должен удаляться, пока не будут переданы все данные из буферов (как приемника так и передатчика, ну или по таймауту. В случае с RST OlegPowerC(103 знак., 09.11.2012 12:13)
        
        Какой стек вы используете? - VVB(09.11.2012 13:13)
        
        Я начал с uIP а закончил своим. Изучаю опыт использования других стеков, чтоб учесть замечания. Вот по поводу изменения окна компом теперь учту и проверю - OlegPowerC(09.11.2012 13:25)
    - Правильно, SciFi(209 знак., 08.11.2012 14:00)
  - Промахнулся - VVB(08.11.2012 13:19, ссылка)

Микроконтроллеры