jcxz 242 19 июня, 2020 Опубликовано 19 июня, 2020 · Жалоба 1 час назад, razrab83 сказал: Где? Как обычно - пустослов. Дайте пруфлинк или копипаст. Понимаете в чем ваша проблема? Какая проблема в вашем общении?.... вы ни когда не можете дать конкретный ответ/совет. Вы не умеете пользоваться гуглом? Тогда вот: https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#Порядковый_номер У меня проблем нет, я умею и поиском пользоваться и мануалы читать. И конкретный совет я дал: Читать описание TCP. На форуме "профессиональных разработчиков электроники" этого должно быть вполне достаточно. Цитата Пруфлинк или трепло? Я вроде вас не оскорблял... И на личности не переходил. Впрочем как я заметил уже тут неоднократно на многих персонажах: хамство и некомпетентность - неотделимые вещи. Цитата В ТСП есть crc, Уже и CRC вдруг откуда-то нарисовалось в TCP. Ещё раз - не несите ахинею! Читайте мануалы. Вы совершенно не разбираетесь в обсуждаемом вопросе. Цитата т.е. там уже встроено crc и не нужно дополительно его делать. Может просветите всех здесь присутствующих: где в TCP CRC? Приведите ссылку, подтверждающую это. Цитата Но ТСП вам не гарантирует автоматическое определение разрыва, ТСП сам не будет ни чего посылать и контролировать, ни какие кипэлайвы . Это нужно делать программисту, как вы пишете, дополнительно. А байты он сам тоже посылает или "это нужно делать программисту"? Никакой протокол сам по себе ничего не делает. Он только даёт необходимые инструменты для этого. Ни байты сам не отсылает ничего другого сам не делает. Делает всегда программист, пишущий TCP-стек. Цитата вы как обычно, живете в фантазиях и каждую строчку, каждую фразу путаете. Я вам говорил, что keep-alive в СОМ я реализовывал врукопашную, т.е. программно, дополнительно - ровно как и вы предлагаете в ТСП keep-alive реализовать программно и дополнительно. Вы не понимаете разницы между прикладным протоколом (любым, например DLMS) и интерфейсом через который он ходит (COM, TCP-сокет). И поэтому у вас в голове такая каша. Реализовать вы могли что-то в протоколе, но никак не в COM-порту (Или вы изобрели свой доморощенный COM-порт?) В чём корневая разница? Если взять какой-то протокол, не имеющий средств определения разрыва соединения, и пустить этот протокол через COM-порт, то обнаружить разрыв никак не получится. Если этот же протокол пустить через TCP-сокет, то разрыв обнаружить получится (последством номеров последовательностей). И вопрос на засыпку: Так значит - где находится средство обнаружения разрыва соединения?: в протоколе или в интерфейсе (канале) через который он ходит?? 2+2 сложить сможете? Цитата Бывает плохому танцору тоже что-то мешает. Но это же не про вас? Конечно (ведь я знаю как в TCP реализовать keep-alive. ) Я даже знаю про кого это. 1 час назад, razrab83 сказал: А теперь внимание откровение для Вас: В TCP сокете keep-alive (в тсп, в сом, в др....) делается именно для соединения, а не для протокола обмена и не зависит от протокола. Почувствуйте разницу! Одни это реализовали аском, вы предлагаете номерами, я делал пустым обменом.... Тогда просим пример в студию: Как сделать обнаружение разрыва соединения (aka keep-alive) не зависимое от протокола через COM-порт. Которое вы типа реализовали где-то. Ведь это - прорыв в технологиях! Ибо такого кроме вас этого никто не умеет! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 19 июня, 2020 Опубликовано 19 июня, 2020 · Жалоба 24 минуты назад, Rst7 сказал: Ну и так желаемый Вами пруф - https://tools.ietf.org/html/rfc1122#page-101 я читал это. во первых это рекомендация, а не требование (не спецификация ТСП).... Это рабочее предложение.... ну и во вторых даже в этом документе чёрным по белому Цитата The TCP specification does not include a keep-alive mechanism Цитата Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 19 июня, 2020 Опубликовано 19 июня, 2020 · Жалоба 1 час назад, mantech сказал: Чет здесь все к стеку-то привязались, контроль линка можно делать читая состояние физики порта... Если уж совсем лень - заведите диод линка на порт МК и читайте... Это малоинформативно. Линк может быть, а сокет - разорваться. 8 минут назад, razrab83 сказал: я читал это. во первых это рекомендация, а не требование (не спецификация ТСП).... Это рабочее предложение.... ну и во вторых даже в этом документе чёрным по белому И что? Написано же: "If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection" - значит если оно нужно (определение разрыа), то аппликация должна это реализовать. А средства для этого в TCP есть. В отличие от COM-порта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 19 июня, 2020 Опубликовано 19 июня, 2020 (изменено) · Жалоба 45 минут назад, jcxz сказал: Тогда вот: https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#Порядковый_номер где там сказано о обнаружении разрыва соединения? 45 минут назад, jcxz сказал: Тогда просим пример в студию: Как сделать обнаружение разрыва соединения (aka keep-alive) не зависимое от протокола через COM-порт. Которое вы типа реализовали где-то. см выше, я уже писал. Цитата Я вроде вас не оскорблял... я вас тоже. 45 минут назад, jcxz сказал: Никакой протокол сам по себе ничего не делает. Он только даёт необходимые инструменты для этого. Ни байты сам не отсылает ничего другого сам не делает. Делает всегда программист, пишущий TCP-стек. Я с вами согласен. Делает программист, пишуший TCP-стек. делающий программную или аппаратную реализацию ТСП стека. Но ТС вроде как всего лишь хочет пк подружить с стм32. Было предложено ТСП. Он не стек пишет, а приложение. 45 минут назад, jcxz сказал: Если взять какой-то протокол, не имеющий средств определения разрыва соединения, и пустить этот протокол через COM-порт, то обнаружить разрыв никак не получится. я вам написал как это можно обнаружить. Цитата Если этот же протокол пустить через TCP-сокет, то разрыв обнаружить получится (последством номеров последовательностей). Если в стеке не реализован механизм keep-alives (а как мы видим из RFC он там не обязан быть реализован), то разрыв, во время простоя, возможно из аппликэйшин обнаружить, только посылая дополнительные пакеты. Цитата Написано же: "If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection" - значит если оно нужно (определение разрыа), то аппликация должна это реализовать. ну наконец-то от вас конкретика... можете ведь нормально общаться... что касается написанного..... если а вам скажу про ваш плохой аглицкий - примете за оскорбление? там написано следующее: Если keep-alives включён, (не, не включён... включён не в смысле turn on, а в смысле реализован.... перефразируй в данном контексте) Если keep-alives реализован, то приложение должно иметь возможность включать и выключать такие пакеты (пакеты keep-alives) для КАЖДОГО ТСП соединения. 45 минут назад, jcxz сказал: Так значит - где находится средство обнаружения разрыва соединения? в протоколе или в интерфейсе... The TCP specification does not include a keep-alive mechanism!!! О чем я сразу сказал, с чем вы не согласны и меня пытаетесь переубедить. Давайте остановимся на этом. Если есть желание поспорить - поспорьте со спецификацией. не являюсь носителем английского и прошу за неточность перевода... вот нашел перевод на великом и могучем.... "If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection" - "При включении keep-alive приложениям должна обеспечиваться возможность запрета таких пакетов для отдельных соединений TCP" пруф Изменено 19 июня, 2020 пользователем razrab83 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 19 июня, 2020 Опубликовано 19 июня, 2020 (изменено) · Жалоба 3 часа назад, razrab83 сказал: ри непрямом подключении у вас линк, на любой ваше сетевухе останется. Каком еще "не прямом"? Вот ноут подключен к роутеру патчкордом, на сетевухе линк показывает, винда тоже знает об этом, вытыкаю разъем линк гаснет, винда тоже вякнула, что провод вытащили. Что-то на "детский сад" смахивает... Если под "не прямым" подразумевать, что роутер от инета отключат, то да, линк не погаснет, разумеется. Тогда только делать периодические пинги удаленного хоста, заодним и связь с ним всегда будет проверена, а не просто с абстрактным инетом. Изменено 19 июня, 2020 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 июня, 2020 Опубликовано 20 июня, 2020 · Жалоба 16 часов назад, razrab83 сказал: где там сказано о обнаружении разрыва соединения? Для человека имеющего голову, там сказано достаточно. 16 часов назад, razrab83 сказал: см выше, я уже писал. Где "выше"? Конкретный пример в студию!: "Как сделать обнаружение разрыва соединения (aka keep-alive) не зависимое от протокола через COM-порт. Которое вы типа реализовали где-то." Ждём. "Пруфлинк или трепло"? Выше я только вижу: "номера кадров TCP", "CRC в TCP" ещё и некая "фрагментация TCP" (чего? байтов на биты что-ль? ). И прочие "перлы", точно характеризующие ваш уровень "знаний" о TCP. 16 часов назад, razrab83 сказал: я вам написал как это можно обнаружить. Где "написал"??? Не вижу. Как протоколо-независимо обнаружить разрыв соединения? "Пруфлинк или трепло"? 16 часов назад, razrab83 сказал: Если в стеке не реализован механизм keep-alives (а как мы видим из RFC он там не обязан быть реализован), то разрыв, во время простоя, возможно из аппликэйшин обнаружить, только посылая дополнительные пакеты. А кто говорил про "стек"? Я говорил про TCP. Про стек я нигде не говорил и никакой не советовал. Но вот почему-то для LwIP оказывается средства для обнаружения разрыва в TCP есть, а для вас - нет. Печалька однако. 16 часов назад, razrab83 сказал: ну наконец-то от вас конкретика... можете ведь нормально общаться... что касается написанного..... если а вам скажу про ваш плохой аглицкий - примете за оскорбление? Остальной пустой трёп от "специалиста" в английском (такого же, как и в TCP ;) поскипан. Ждём конкретных ответов на конкретные вопросы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 21 июня, 2020 Опубликовано 21 июня, 2020 (изменено) · Жалоба 20.06.2020 в 10:55, jcxz сказал: Где "написал"??? Не вижу. я писал выше в этой теме. если вы не видите (читаете не внимательно), не вижу смысла писать ещё раз... 19.06.2020 в 17:31, jcxz сказал: Может просветите всех здесь присутствующих: где в TCP CRC? Приведите ссылку, подтверждающую это. CRC - (она же контрольная сумма, или checksum, имелось это в виду), Чтоб вы тут не лопнули, пытаясь доказать, что CRC != checksum, ...... вместо "контрольная сумма" часто говорят crс, из-за краткости. Более того.... см ваш вики в анг, вот вам пруф на crc в tcp 20.06.2020 в 10:55, jcxz сказал: ещё и некая "фрагментация TCP" (чего? байтов на биты что-ль? ). "сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Это приводит к фрагментации и уменьшению скорости передачи полезных данных." пруф на вашу же вики. Ваши "перлы", точно характеризуют ваш уровень "знаний" о TCP. Вы бы хотя бы свою вики почитали. 20.06.2020 в 10:55, jcxz сказал: А кто говорил про "стек"? Я говорил про TCP. Про стек я нигде не говорил и никакой не советовал. я говорю про TCP. В TCP нет keep-alive.... The TCP specification does not include a keep-alive mechanism!!! Прикладной программист, использующий TCP как транспорт как безошибочный COM-порт ( с чего и возник мой вопрос), берёт готовый стек (программный или аппаратный) и использует его. Стек, как правило имеет API на открытие сокета, закрытие, прослушку, отправку данных и чтение. Номера последовательностей, crc контрольную сумму и т.п. - это всё скрыто за API. И если в стеке TCP нет реализации keep-alive, то ..... Цитата Заботу об ошибках берет на себя TCP. Вот именно. Но TCP не заботится о keep-alive. (Если не согласен, читай The TCP specification does not include a keep-alive mechanism! и если со спецификацие не согласен - пиши авторам в адрес). В LwIP стек на себя взял заботу keep-alive. 19.06.2020 в 20:41, mantech сказал: Каком еще "не прямом"? Вот ноут подключен к роутеру патчкордом, ..... я же писал выше. Девайс-Хаб-(облако)-ПК. Вот ноут подключен к роутеру патчкордом, ваш девайсStm32 также подключен к этому же роутеру пачкордом. Везде "горят" линки. Ваш ноут установил соединение с девайсStm32 (локально, без выхода в инет). Выдерните пачкорд из девайсStm32 - на ПК в сетевухе будет гореть линк, и винда не обнаружит что кабель из девайсStm32 выдернули. Изменено 21 июня, 2020 пользователем razrab83 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 22 июня, 2020 Опубликовано 22 июня, 2020 · Жалоба 19 часов назад, razrab83 сказал: я писал выше в этой теме. если вы не видите (читаете не внимательно), не вижу смысла писать ещё раз... Слив засчитан. Значит всё-таки "трепло".... 19 часов назад, razrab83 сказал: CRC - (она же контрольная сумма, или checksum, имелось это в виду), Чтоб вы тут не лопнули, пытаясь доказать, что CRC != checksum, ...... вместо "контрольная сумма" часто говорят crс, из-за краткости. Более того.... см ваш вики в анг, вот вам пруф на crc в tcp Слово "CRC" вы там нашли, но понять содержание фразы не сумели. "Смотрю в книгу вижу фигу"... 19 часов назад, razrab83 сказал: "сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Это приводит к фрагментации и уменьшению скорости передачи полезных данных." пруф на вашу же вики. Ваши "перлы", точно характеризуют ваш уровень "знаний" о TCP. Вы бы хотя бы свою вики почитали. Опять "Слышу звон, но не знаю о чём он".... PS: С вами говорить о чём-либо по TCP (да и не только) бесполезно. А вменяемые люди знают: 1) На соединении через COM-порт в принципе невозможно протоколонезависимо обнаружить обрыв соединения (без привлечения каких-то дополнительных инструментов типа сигналов CTS/RTS и т.п.); 2) TCP с точки зрения пользователя сокета - это байтовый поток поэтому понятие "фрагментация" к нему не применимо, просто нечему там фрагментироваться; 3) в TCP нет кадров как, соответственно, и нет их номеров; 3) CRC != checksum. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 23 июня, 2020 Опубликовано 23 июня, 2020 (изменено) · Жалоба 22.06.2020 в 12:49, jcxz сказал: Слив засчитан. Значит всё-таки "трепло".... Конечно, вам слив засчитан, .... всё-таки трепло... вам что от меня нужно? вы мне что хотите доказать? The TCP specification does not include a keep-alive mechanism! Я с самого начала ровно сказал тоже самое - в TCP нет keep-alive. Или вы хотите доказать, что в TCP можно сделать keep-alive - так кто с этим спорит - делайте. 19.06.2020 в 17:31, jcxz сказал: И конкретный совет я дал: Читать описание TCP. это не конкретный совет. конкретный совет/ответ дал Сергей Борщ, gerber, mantech, Rst7. Вы не смогли указать, где в спецификации TCP есть keep-alive. То, что его можно дополнительно реализовать, я и без вас знаю. Если вы уже выучили, как и где определён этот самый uint_fast8_t? Последуйте своему же совету: Читать описание TCP, чтобы не пороть очередную чушь (С). 19.06.2020 в 17:31, jcxz сказал: Если взять какой-то протокол, не имеющий средств определения разрыва соединения, и пустить этот протокол через COM-порт, то обнаружить разрыв никак не получится. если вам не получиться, это не значит, что ни кому не получиться. ещё раз, как я на com в рукопашную делал keep-alive.... 19.06.2020 в 17:31, jcxz сказал: Если взять какой-то протокол... прямо, спешал4ю, шагзашагом.... берём протокол... на вскидку... FD00042 19.06.2020 в 17:31, jcxz сказал: не имеющий средств определения разрыва соединения Этот протокол не имеет средств определения разрыва соединения. 19.06.2020 в 17:31, jcxz сказал: и пустить этот протокол через COM-порт пускаем этот протокол через COM, использую только TxD и RxD. 19.06.2020 в 17:31, jcxz сказал: то обнаружить разрыв никак не получится. То, что вам не получиться обнаружить разрыв, это уже все поняли. Я обнаруживаю разрыв следующим образом: Если нет активного обмена с устройством в течении времени t1, то читаю идентификатор устройства. Если устройство не ответило несколько раз подряд, то считаю что имеет место разрыв (или устройство вышло из строя) и помечаю "нет связи с устройством". Ровно об этом я и говорил, когда сказал 19.06.2020 в 08:20, razrab83 сказал: этот тот же рукопашный keep-alive как и для ком-порта Что я сказал про компорт не так? Не нравиться пример на протоколе FD00042 - замените FD00042 на Modbus-RTU. Если нет активного обмена с устройством в течении времени t1, то читаю_нужный_регистр/читаю_несуществующий_регистр/отправляю_устройству_команду_тест_связи/отправляю_устройству_не_поддерживаемую_команду (нужное подчеркнуть). Если устройство не ответило несколько раз подряд, то считаю что имеет место разрыв (или устройство вышло из строя) и помечаю "нет связи с устройством". Вы мне что пытаетесь доказать? Что я так не делал? Или что это сделать не возможно? Мне возможно. Вам видимо нет, так как плохому танцору вам мешают ... мешает протокол обмена, о чем вы сами и заявили 19.06.2020 в 14:57, jcxz сказал: Мешает протокол обмена. мне, в отличии от вас, протокол обмена это сделать не помешал. PS: С вами говорить о чём-либо по TCP (да и не только) бесполезно. А вменяемые люди знают: 1) На соединении через COM-порт возможно программно организовать проверку соединения без привлечения каких-то дополнительных инструментов типа сигналов CTS/RTS 2) ух ты!!! TCP с точки зрения пользователя сокета!!! Уже взгляд с точки зрения сокета?! С точки зрения пользователя сокета номера последовательностей недоступны. 3) Что за кадры вы придумали? Новые ваши "перлы", точно характеризующие ваш уровень "знаний" о TCP (С). Вы придумали в этой теме кадры, теперь кому-то доказываете что там нет кадров? ))) Я тут редко бываю.... с вам наверно в 3-ий раз вступаю в диалог, и в 3-ий раз вы за оппонентов что-то своё додумываете, и потом что-то им приписываете и потом всем начинаете что-то доказывать и спорить. Зачем? pps 20.06.2020 в 10:55, jcxz сказал: Выше я только вижу: "номера кадров TCP" человек точно под алкоголем/веществам/COVID19 не вменяемый . Начинает мерещиться всякое.... Модераторы, дайте бан отправте на карантан на пару недель jcxz. Видно же, что человек не в себе. ppps Если вы уже выучили, где и как определён uint_fast8_t и как найти stdint.h, и есть время свободное, но вы не можете ни как осилить TCP, то пожалуйста, выучите хотябы это - The TCP specification does not include a keep-alive mechanism и постарайтесь понять смысл. Изменено 23 июня, 2020 пользователем razrab83 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 23 июня, 2020 Опубликовано 23 июня, 2020 · Жалоба 19.06.2020 в 15:31, jcxz сказал: Тогда просим пример в студию: Как сделать обнаружение разрыва соединения (aka keep-alive) не зависимое от протокола через COM-порт. Которое вы типа реализовали где-то. 5 часов назад, razrab83 сказал: То, что вам не получиться обнаружить разрыв, это уже все поняли. Я обнаруживаю разрыв следующим образом: Если нет активного обмена с устройством в течении времени t1, то читаю идентификатор устройства. Если устройство не ответило несколько раз подряд, то считаю что имеет место разрыв (или устройство вышло из строя) и помечаю "нет связи с устройством". Да уж.... нет слов... можно как анекдот рассказывать. И в цирк ходить не нужно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
