[razrab83 17]

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

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

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

[Сергей Борщ 119]

В 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.

[jcxz 184]

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

В TCP есть keep-alive?

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

[razrab83 17]

1 час назад, Сергей Борщ сказал:

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

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

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

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

там нет keepalive.

11 минут назад, razrab83 сказал:

1 час назад, Сергей Борщ сказал:

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

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

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

Изменено 19 июня, 2020 пользователем razrab83

[jcxz 184]

13 минут назад, razrab83 сказал:

там нет keepalive.

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

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

[razrab83 17]

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

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

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

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

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

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

[jcxz 184]

9 минут назад, razrab83 сказал:

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

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

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

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

[razrab83 17]

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

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

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

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

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

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

Цитата

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

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

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

Цитата

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

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

 

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

Изменено 19 июня, 2020 пользователем razrab83

[gerber 7]

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

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

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

[jcxz 184]

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

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

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

Цитата

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

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

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

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

Цитата

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

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

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

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

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

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

[mantech 34]

12.06.2020 в 09:28, DDDDRRRRR сказал:

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

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

Изменено 19 июня, 2020 пользователем mantech

[razrab83 17]

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 сказал:

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

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

[Rst7 5]

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.

[mantech 34]

58 минут назад, razrab83 сказал:

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

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

[razrab83 17]

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

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

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