Jump to content

    
DDDDRRRRR

TCP сервер на stm32

Recommended Posts

12 часов назад, gerber сказал:

Если включить keep-alive , то с определением выдергивания кабеля.

В TCP есть keep-alive? я делал рукопашный keep-alive для TCP. По сути этот тот же рукопашный keep-alive как и для ком-порта (т.е. смена COM на TCP  тут преимуществ не даст). Возможно keep-alive уже реализован в каком нибудь стеке, типа LWIP. Кто в курсе?

Share this post


Link to post
Share on other sites

В LWIP точно реализован. 

    {
        int Value = 1;
        lwip_setsockopt(New_socket, SOL_SOCKET, SO_KEEPALIVE, &Value, sizeof(Value));
    }

Также обратите внимание на #define LWIP_TCP_KEEPALIVE. Его включение добавляет возможность менять TCP_KEEPIDLE, TCP_KEEPINTVL TCP_KEEPCNT (как именно - легко найти поиском в исходниках по "LWIP_TCP_KEEPALIVE"). Если не включить, будут использоваться прибитые гвоздями значения по-умолчанию TCP_KEEPIDLE_DEFAULT, TCP_KEEPINTVL_DEFAULT, TCP_KEEPCNT_DEFAULT.

Share this post


Link to post
Share on other sites
2 часа назад, razrab83 сказал:

В TCP есть keep-alive?

Почитайте описание TCP. Особенно - про номера последовательностей (входящий и исходящий).

Share this post


Link to post
Share on other sites
1 час назад, Сергей Борщ сказал:

В LWIP точно реализован. 

Я другим стеком пользовался, там не было. Про lwip буду иметь в виду, спс.

1 час назад, jcxz сказал:

Почитайте описание TCP. Особенно - про номера последовательностей (входящий и исходящий).

там нет keepalive.

11 минут назад, razrab83 сказал:
1 час назад, Сергей Борщ сказал:

В LWIP точно реализован. 

Я другим стеком пользовался, там не было. Про lwip буду иметь в виду, спс.

Хотя... минуточку.... а Вы им пользовались? Реализация keepalive  зависит от стека. в ТСР нет пакетов keepalive. Если прибор с ТСР(lwip) подключить к устройству, в котором нет lwip, и в котором нет надстройки keepalive? Или в котором keepalive реализован по другому....  ?

Edited by razrab83

Share this post


Link to post
Share on other sites
13 минут назад, razrab83 сказал:

там нет keepalive.

Странно... А откуда тогда LwIP его умеет, как думаете? У него какой-то свой особенный TCP, думаете?  :biggrin:

Всё-таки стоит внимательнее почитать описание TCP. И подумать: "Как можно организовать keep-alive посредством номеров последовательностей TCP"?

Share this post


Link to post
Share on other sites
3 минуты назад, jcxz сказал:

Всё-таки стоит внимательнее почитать описание TCP.

"Ты суслика видишь? а он там есть" (С). пруфлинк или ....?

5 минут назад, jcxz сказал:

"Как можно организовать keep-alive посредством номеров последовательностей TCP"?

сами себе противоречите. Вы уже определитесь - он keepalive там  в ТСР ЕСТЬ? Или его нужно организовать?

Share this post


Link to post
Share on other sites
9 минут назад, razrab83 сказал:

сами себе противоречите. Вы уже определитесь - он keepalive там  в ТСР ЕСТЬ? Или его нужно организовать?

Для того чтобы что-то сделать, нужно 2 вещи: 1) возможности (они в TCP как видим есть); 2) способности делающего (тут у всех по-разному). 

А значит, для имеющих способности - он есть. :unknw:

PS: А мне вот интересно - откуда keep-alive в COM-порту взялся, где отродясь не было никаких средств для его организации? Не поделитесь секретом?  :wink:

Share this post


Link to post
Share on other sites
1 час назад, jcxz сказал:

Для того чтобы что-то сделать, нужно 2 вещи: 1) возможности (они в TCP как видим есть); 2) способности делающего (тут у всех по-разному). 

А значит, для имеющих способности - он есть. :unknw:

PS: А мне вот интересно - откуда keep-alive в COM-порту взялся, где отродясь не было никаких средств для его организации? Не поделитесь секретом?  :wink:

вы как всегда путаете мягкое с тёплым. по порядку....

в ТСР контроля (внезапного) разрыва соединения нет. Это его (этого протокола) недостаток. Этот недостаток компенсируется надстройкой (в ОС, в реализации стека, в программе). Можно самому по таймеру слать контрольный пакет и получать ответ. если тишина - коллбакДисконнект(); (может кто-другой предложит др алгоритм.... в студию).

Цитата

Для того чтобы что-то сделать, нужно 2 вещи: ...

дальше можно не читать. Ни кто не говорит, что это невозможно СДЕЛАТЬ. В рамках протокола ТСР ни каких keep-alive нет. Для "автоматического" определения выдергивания кабеля (я не имею в виду link, т.к. кабель можно дернуть в др сегменте сети и link останется) нужно (правильно вы говорите) СДЕЛАТЬ. Сергей Борщ говорит, что в lwip это сделано.

Далее... чтобы вы понимали что такое "автоматическое определение выдернутого кабеля", о коем идет речь, посмотрите USB.

Цитата

PS: А мне вот интересно - откуда keep-alive в COM-порту взялся, где отродясь не было никаких средств для его организации? Не поделитесь секретом?

должно быть стыдно за этот ps. см как сделали keep-alive в ТСП, например тут. Кто вам мешает по COM  посылать АСК контрольные пакеты  и если не было ответа, то принимать решение, что соединение разорвано?

 

ps а как можно реализовать keep-alive обнаружение выдернутого кабеля по номерам пакетов ТСП? Не поделитесь секретом? (чтоб вы опять пустых реплик, типа "читай гугл да вразуми" не писали... вот вам ситуация... установили соединение между 2-мя устройствами по тсп. обменялись данными.... и..... пока нет необходимости в обмене... минуту нет обмена... две минуты... 100 минут... 10 дней.....   3 года нет обмена - можно уже считать что кабель выдернули? Как это покажет нумерация пакетов ТСП?)

Edited by razrab83

Share this post


Link to post
Share on other sites
2 часа назад, jcxz сказал:

PS: А мне вот интересно - откуда keep-alive в COM-порту взялся, где отродясь не было никаких средств для его организации? Не поделитесь секретом?  :wink:

В COM-порту выдернутый кабель можно обнаружить по пропавшему сигналу CTS, только кабель должен быть полноценный, c RTS/CTS жилами.

Share this post


Link to post
Share on other sites
1 час назад, razrab83 сказал:

в ТСР контроля (внезапного) разрыва соединения нет. Это его (этого протокола) недостаток. Этот недостаток компенсируется надстройкой (в ОС, в реализации стека, в программе). Можно самому по таймеру слать контрольный пакет и получать ответ.

Вы упорно не желаете читать описание TCP. Пытаетесь городить какие-то "контрольные пакеты", хотя в TCP всё нужное есть. Имеющий уши - да услышит, глаза - да увидит. Дело ваше....

Цитата

должно быть стыдно за этот ps. см как сделали keep-alive в ТСП, например тут. Кто вам мешает по COM  посылать АСК контрольные пакеты  и если не было ответа, то принимать решение, что соединение разорвано?

Мешает протокол обмена. Что за "ACK контрольные пакеты" и какое отношение они имеют к UART? Если нужно работать через UART по протоколу где нет доморощенных ACK-пакетов  - это уже не UART?

Если вы сделали какие-то спец.пакеты в своём протколе обмена, то они относятся только к вашему протоколу, а не к UART. "Не нужно путать мягкое с тёплым" (c) ваш

А теперь внимание откровение для Вас: В TCP сокете keep-alive делается именно для соединения, а не для протокола обмена и не зависит от протокола. Почувствуйте разницу! Неожиданно, да? :russian_ru:

Цитата

ps а как можно реализовать keep-alive обнаружение выдернутого кабеля по номерам пакетов ТСП? Не поделитесь секретом?

Что такое "номера пакетов ТСП"? Откуда вы это взяли? Нет такого в TCP! Ещё раз советую: почитайте уже наконец-то описание TCP. Чтобы не пороть очередную чушь.

Тем кто прочитал и понял работу TCP это должно быть очевидно: Достаточно периодически отправлять текущее состояние номеров последовательностей TCP (Sequence number / Acknowledgment Number) и контролировать их получение на другой стороне. Вот и весь keep-alive.

37 минут назад, gerber сказал:

В COM-порту выдернутый кабель можно обнаружить по пропавшему сигналу CTS, только кабель должен быть полноценный, c RTS/CTS жилами.

Вот именно. А ещё и COM-порт - железный, а не виртуальный например. Т.е. - только сторонними опциональными средствами.

Share this post


Link to post
Share on other sites
12.06.2020 в 09:28, DDDDRRRRR сказал:

зажечь, потушить светодиод и тд. МК - stm32f746 dicovery, PHY - LAN8742.

Чет здесь все к стеку-то привязались, контроль линка можно делать читая состояние физики порта... Если уж совсем лень - заведите диод линка на порт МК и читайте...

Edited by mantech

Share this post


Link to post
Share on other sites
7 минут назад, jcxz сказал:

Вы упорно не желаете читать описание TCP. Пытаетесь городить какие-то "контрольные пакеты", хотя в TCP всё нужное есть. Имеющий уши - да услышит, глаза - да увидит. Дело ваше....

Где? Как обычно - пустослов. Дайте пруфлинк или копипаст.  Понимаете в чем ваша проблема? Какая проблема в вашем общении?.... вы ни когда не можете дать конкретный ответ/совет. Даже в рамках последней дискусии - gerber, Сергей Борщ дали короткий ясный ответ/совет. Всё понятно. Что вы тут устроили? 

 

3 часа назад, razrab83 сказал:

"Ты суслика видишь? а он там есть" (С). пруфлинк или ....?

  перефразирую, для тех, кто в танке    - я внимательно посмотрел описание ТСР. Я не нашел там "встроенное" определение внезапного разрыва соединения. Скорее всего, перед тем, как вы дали совет "повнимательней прочитать описание ТСП", вы сами открыли и прочитали это описание, чтобы убедиться, что вы ни чего не путаете. Так вот, я прошу вас дать мне ссылку на это описание и на тот раздел, где говориться том, каким образом ТСП определит обрыв кабеля? Пруфлинк или трепло?

53 минуты назад, jcxz сказал:

Вы упорно не желаете...

Вы упорно не желаете дать конкретный ответ, только на подобие "Имеющий уши - да услышит, глаза - да увидит." Сплошной троллинг.

21 минуту назад, jcxz сказал:

Что такое "номера пакетов ТСП"?

 номера последовательностей (входящий и исходящий).

 

23 минуты назад, jcxz сказал:

Достаточно периодически отправлять текущее состояние номеров последовательностей TCP (Sequence number / Acknowledgment Number) и контролировать их получение на другой стороне. Вот и весь keep-alive.

пфффф...... так этого НЕТ в ТСП ТСП сам ни чего отправлять и контролировать не будет.  В ТСП есть crc, есть фрагментация, есть номера последовательностей и много чего. ТСП вам гарантирует доставку данных без ошибок, т.е. там уже встроено crc и не нужно дополительно его делать. Но ТСП вам не гарантирует автоматическое определение разрыва, ТСП сам не будет ни чего посылать и контролировать, ни какие кипэлайвы . Это нужно делать программисту, как вы пишете, дополнительно. Ровно как и в СОМ.

3 часа назад, jcxz сказал:

PS: А мне вот интересно - откуда keep-alive в COM-порту взялся, где отродясь не было никаких средств для его организации? Не поделитесь секретом?  

вы как обычно, живете в фантазиях и каждую строчку, каждую фразу путаете. я вам не говорил, что в СОМ есть keep-alive , что СОМ может сам обнаружить обрыв. Я вам говорил, что keep-alive в СОМ я реализовывал врукопашную, т.е. программно, дополнительно - ровно как и вы предлагаете в ТСП keep-alive реализовать программно и дополнительно. 

40 минут назад, jcxz сказал:

это уже не UART?

UART

40 минут назад, jcxz сказал:

Мешает протокол обмена.

Бывает плохому танцору тоже что-то мешает. Но это же не про вас?

42 минуты назад, jcxz сказал:

Если нужно работать через UART по протоколу где нет доморощенных ACK-пакетов 

У меня был как и свой доморощенный протокол, так и стронние. На вскидку, Modbus-RTU, хотя там и есть тестовые команды, которые разрабы леняться реализовывать ( или мало место в мк), можно читать один и тот же регистр с таймаутом keep-alive_timeout и далее все как реализовано в.... в моей ссылке выше. Можно послать команду несуществующую, слэйв должен вернуть ответ с кодом ошибки.... в немодбасе - также, делай обмен периодический (что-нибудь читай короткое, без всяких спец пакетов).

1 час назад, jcxz сказал:

А теперь внимание откровение для Вас: В TCP сокете keep-alive делается именно для соединения, а не для протокола обмена и не зависит от протокола. Почувствуйте разницу! Неожиданно, да? 

А теперь внимание откровение для Вас: В TCP сокете keep-alive (в тсп, в сом, в др....) делается именно для соединения, а не для протокола обмена и не зависит от протокола. Почувствуйте разницу! Одни это реализовали аском, вы предлагаете номерами, я делал пустым обменом.... не важно как это реализованно, но делается именно для соединения. Неожиданно, для вас это наверно, да? Вам неожиданно то, что вы мне что-то доказываете... что-то свое.. вы придумали, что я утверждаю кипэлайв для протокола. Но это не так, я этого вам не говорил. я почти на протяжении всех постов говорю "разрыв соединения".  Перечитайте мои посты. Неожиданно, да? 

 

14 минут назад, mantech сказал:

контроль линка можно делать читая состояние физики порта...

речь не о контроле линка, а определение выдергивание кабеля. подключитесь Девайс-Хаб-(облако)-ПК. Дерните пачкорд из ПК. Линк на вашем девайсе не пропадет.

Share this post


Link to post
Share on other sites
43 minutes ago, razrab83 said:

Где? Как обычно - пустослов. Дайте пруфлинк или копипаст.  Понимаете в чем ваша проблема? Какая проблема в вашем общении?.... вы ни когда не можете дать конкретный ответ/совет.

Уважаемый, у Вас тоже явная проблема в общении. И бан в гугле выписан, как я посмотрю.

43 minutes ago, razrab83 said:

я внимательно посмотрел описание ТСР.

И во внимательности и вообще в способности ориентироваться в RFC, относящихся к TCP, например. Потому что есть еще RFC1122 "Requirements for Internet Hosts -- Communication Layers".

 

Ну и так желаемый Вами пруф - https://tools.ietf.org/html/rfc1122#page-101

 

И вообще там раздел 4.2 говорит очень многие вещи, которых нет в RFC793.

Share this post


Link to post
Share on other sites
58 минут назад, razrab83 сказал:

подключитесь Девайс-Хаб-(облако)-ПК. Дерните пачкорд из ПК. Линк на вашем девайсе не пропадет.

Да хоть к спутнику подключитесь, причем напрямую :biggrin:. Если ваша сетевуха не гасит линк при выдергивании кабеля выкиньте ее на свалку...

Share this post


Link to post
Share on other sites
2 минуты назад, mantech сказал:

Да хоть к спутнику подключитесь, причем напрямую :biggrin:. Если ваша сетевуха не гасит линк при выдергивании кабеля выкиньте ее на свалку...

при непрямом подключении у вас линк, на любой ваше сетевухе останется. можете прямо сейчас посоветовать своему совету и выкинуть все свои сетевухи:biggrin:.


 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.