Отговори на тема  [ 74 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5  Следваща
LWIP MQTT TCP flow control въпросче... 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Двата предишни поста щяха да имат смисъл ако нещо беше "обяснено", или поне да има въпрос "ама как ще направиш еди какво си в еди каква си ситуация?"
Но в текущия им вид няма входни данни, така че няма какво да отговоря.
Ако някой има време да включи мозъка и да мислим по избистрилата се тема "как, аджеба, mqtt може да се ползва практически за ембедед устройства" е добре дошъл.
Констатации как се е комуникирало през Средновековието, или в по-близкото минало, са интересни също - е, може да се наложи да разчекнем темата на "архивите са живи", щото предлогам накъде ще тръгне - "тъй не се прави", "аз ти казвам не го прави така", "аз го правя еди как си и не може да има друг начин", и ще стигне до "не ти е ясна идеята".


Съб Окт 28, 2017 1:38 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: LWIP MQTT TCP flow control въпросче...
не че не става - става, но не е стабилен протокола - тва искам да ти обясня, не е развит за големи пакети от данни
ако го ползваш в бавни мрежи ще е страшно
пример: GPRS латентност на MQTT пакет ~1 секунда(MTEL),
1 Mbyte = 1024 секунди по две за аск......... над 15 минути трансфер
а ако някой ти прати PUB през това време 50/50 щи дропне mqtt-то

прави си го нормално - не си хаби времето с изгубени каузи

_________________
main[-1u]={1};


Съб Окт 28, 2017 3:00 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
gicho написа:
щото предлогам накъде ще тръгне - "тъй не се прави", "аз ти казвам не го прави така", "аз го правя еди как си и не може да има друг начин", и ще стигне до "не ти е ясна идеята".


Повечето съвети ти са дедени уж за добро, ама като не вярваш, прави го както си го решиш.
Няма проблем за нас ;-)


Съб Окт 28, 2017 3:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Окт 31, 2004 8:19 pm
Мнения: 4410
Местоположение: Stara Zagora
Мнение Re: LWIP MQTT TCP flow control въпросче...
GPRS латентност на MQTT пакет 200 bytes QOS1. 0.3 ... 12 секунди(MTEL, Стара Загора, 24 часа измерване)
Предполагам средната е както си я сметнал. Мен ме интересуваха границите.


Съб Окт 28, 2017 4:15 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: LWIP MQTT TCP flow control въпросче...
и друг път съм го писал, но явно трябва да обясня пак.

един винт за дърво може да се забие с клещи.
по-добре се забива с чук.
но най-добре става с отвертка.

ти искаш да построиш Айфеловата кула с винтове за дърво. може и да стане, но хората навремето са го направили с горещо формовани нитове и тук-таме болтове за метал (болта не е винт). и конструкцията някак си е издържала 140 години. затова и моя скепсис относно дървените винтове.

искам да кажа, че за всяко нещо си има подходящия инструмент. целите на MQT са едни, файловия обмен е друга цел. обмена на големи файлове в несигурна среда - съвсем трета бира. не разбирам съвсем нуждата от трансфер на 1 гигабайт към MQTT нод, но да кажем, че имаш такава нужда (по дефиниция MQTТ са малки и тъпи устройства, изпъляващи едва няколко функции). в такъв случай ползвай по предназначение MQTT за малки данни и някой протокол за файлов обмен за големите данни. това, което се опитваш да ни убедиш че е добре да се направи е, като се разклати върха на кулата, да забиваш с клещи винтове в основата (да бъзикаш из долните етажи на IP стека). може и да стане, не отричам. но няма да е красиво.

очевидно не страдаш от липса на памет в нода (иначе къде ще ги денеш тия гигабайти). вече имаш имплементиран IP стек + MQTT протокол върху него. какъв ти е проблема да добавиш още един TFTP протокол и да стане ясно и разбираемо? след година самия ти ще си забравил детайлите, камоли ако някой друг трябва да ти пипне кода - ще има да се пули от къде тече водата.


Съб Окт 28, 2017 5:12 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
Човекът не иска да добавя нито TFTP нито нещо друго. Нито сега нито в бъдеще, затова като се получи пакет и директно отива към mqtt.
Казах му че не се прави така, ама на него така му харесвало и нямало смисъл да пипа кода щото пак така щял да го направи по същия начин :D


Съб Окт 28, 2017 5:23 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Пон Юни 05, 2006 12:48 pm
Мнения: 4393
Местоположение: където небето среща земята, ракията е Jameson, а бирата Guinness
Мнение Re: LWIP MQTT TCP flow control въпросче...
Абе то всичко може да се "кирилизира" ако иска бека се поти.
Да не стане:инж.Ганев успя да направи най-дългото късо съединение(в нашият случай ще най-дългото кратко съобщение) :)

_________________
... ако трети ден не ти се работи... това означава, че е сряда !


Съб Окт 28, 2017 7:10 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
ДедоБоре написа:
... какъв ти е проблема да добавиш още един TFTP протокол и да стане ясно и разбираемо? след година самия ти ще си забравил детайлите, камоли ако някой друг трябва да ти пипне кода - ще има да се пули от къде тече водата.

Никакъв не ми е проблема с добавянето, TFTP в по-специфичен вариант го има от години в тия устройства - ама айде да не го размахваме него в защита на това че има по-добри протоколи - не е цвете за мирисане, даже е друго дето мирише. За кого ще е по-разбираемо след година? Да не би да имаш информация че MQTT ще изчезне като стандарт? Нали и без това го недолюбвате понеже е "lightweigth", сега ако кажете че е и сложен...
Но понеже зачекваш смислена посока, кажи ми какво повече ще постигна с TFTP, или FTP, или HTTP (клиенти+сървъри сигурно ще ме накарате скоро да вкарам) и как го виждаш да се впише когато единия или даже и двата края са някъде за NAT дълбоко в локалната мрежа? Сигурното решение да сложа по едно "скромно" VPN-че в двата нода и съм готов?
Защото задачата не е "файла да се вземе от еди къде се", задачата е "файла" или по-точно данните/съобщението, да тръгне от едно затънтено място в дълбоката провинция примерно и да стигне до друго затънтено място в Занзибар по време на военен преврат...
А за винтовете за дърво съм съгласен, но от друга гледна точка - навремето са набивали гвоздеи - да кажем 1000 години, някой е измислил винт/нит или болт и ти ми казваш че досега всички са сковавали кочините с гвоздей, болтовете ги правят за други неща, тъй че металната конструкция да я "кова" с теслата вместо да връткам с импакт драйвера... Или кочината, ако се наложи, да кова вместо да въртя винтове?
Искам да кажа че докато не се убедя, т.е. да натрупам факти (от собствен или чужд опит) че това "новото" (mqtt) има кусури за да свърши определената задача не мисля да го отказвам щото ми е комфортно да карам по старому. ftp, http, tftp и половин дузина "наши" udp и tcp протоколи си ги има и сега вътре - и опита е че са, сори за израза, "недоклатени". Тъй де, дървени клинове в ерата на самопробивни винтове. И реално задачата за която ми плащат е да видя къде са му границите и за какво. Тъй де, дори от бачкаторска гледна точка не ми е изгодно да кажа - едни пращат температура от ардуино - явно само за такова става...

Миро, не знам какво твърдиш с това "директно отива към MQTT" - ако е отворена връзка, и дойде пакет понеже сме заявили интерес към него, да тогава отива към ПРЕЗ mqtt КЪМ софтуерния модул който консумира тия данни - файлова система май давах за пример в началото, но за пълнота си представи всяка една възможна "входна" точка която имаш в устройството - през шел, RPC, HTTP, и т.н. Т.е. не е един тип пакет, ами са една торба различни за към различни точки вътре. И да, всичките минават през MQTT-то, както и през TCP-то.
Ако услугата там иска парченца по 1К - хубаво, всичко си работи, и даже няма нужда от подобрение. Ако ли пък каже 1Мбайт (фирмуер ъпдейт?) - ей го на само че може да се наложи да разреши моя пач. Засега го тествам преди да го пусна, ама то го обсъдихме какво е така че едва ли ще е проблем някой да го пресъздаде.
А "човекът" (дето си няма и идея какво е mqtt както разбрахме) не се дърпа да слага нови неща - напротив, нали затова вкарвам MQTT-то? Казах, в системата има вече http сървър, tftp, по едно време имаше и FTP ама не помня клиент или сървър, има няколко броя наши "message"-ориентирани протоколи - един по TCP и USB, един UDP, и се сещам за още един UDP. Къде го видяхте лесното със "специализираните" протоколи? Кофтито е че нито един от посочените налични протоколи не върши работа вече, в смисъл по единия е удобно да направиш едно, по другия друго, и клиента бръчка чело и иска, а ние се ядосваме "абе тоя пак е чел нещо в интернет..."
Конкуренцията не спи и не кове кочини, та се налага да проучваме базови неща, дето са ни убягнали докато сме се "подковавали" на сигурно...

Първото условие за какъвто и да е протокол (нов или стар) е да поддържа publish-subscribe. Точка. Голяма точка. Няма друго след точката.
Ако ми подхвърлите друга опция, която да мине през филтъра за точката ще черпя. Ако ще ми давате като алтернатива TFTP (ух, амазон и сие дали го имат като услуга в облаците си?) няма да мине. Ако ще се питаме защо pub-sub да отворим тема в академията че тука ще се червим...
Нуждата от друг протокол не е за красота - ако можеше да се прави по UDP примерно защо да се мъчим? Казваме лимит до 1К да влезе наведнъж и ... заклащаме краката в чакане на лятото, то всичко си го има. Т.е. в случая на TCP транспорт търсим нерешените проблеми (в тцп-то) и правим горен протокол за тяхното решение. Ако нямаше ретрансмит, флоу контрол, чексуми щяхме да ги правим (както ги правехме по серийните портове). Но там има един проблем, по-точно излизаме от областта на TCP (според слоестия модел за който спомена Миро). И получаваме непрекъснат стрийм от данни - байтове. Ако имахме да прехвърлим данните от едно 8-битово АЦП към един 8-битов ЦАП сме готови и пеем (ех, точно ако е пеене ще се оакаме де). Но нямаме тоя късмет - трябва команди, статуси и по-сложни гадости да тичат, че и синхронизация. Затова идва отгоре нещо дето може да каже "ей тука почва пакет, ей тука свършва, ей това му са данните, верен е, давам го нататък".

Муха, каква кирилизация? Нали ти казвам че "протокол по второ направление" ще внасям и не мисля да го "подобрявам" с разширения за ftp, а ти ми говориш че ще "побългарявам" :D


Нед Окт 29, 2017 12:06 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
TheWizard написа:
не че не става - става, но не е стабилен протокола - тва искам да ти обясня, не е развит за големи пакети от данни
ако го ползваш в бавни мрежи ще е страшно
пример: GPRS латентност на MQTT пакет ~1 секунда(MTEL),
1 Mbyte = 1024 секунди по две за аск......... над 15 минути трансфер
а ако някой ти прати PUB през това време 50/50 щи дропне mqtt-то

прави си го нормално - не си хаби времето с изгубени каузи

Тия измервания при какви скорости на TCP-то са? Щото QoS 0 няма друг overhead освен започващия, само TCP ACK-та наобратно. Ако те се бавят значи всичко по TCP ще реве. Ако изрежеш TCP-то за да вдигнеш скорост или губиш надеждността, или я пренаписваш на по-горно ниво. Имаше 1-2 такива протокола за reliable UDP, имаше и някакво напълно отделно, ама ми се струва че повече главоболия ще има.
Ако искаш QoS1 или 2 нямаш грижи пак - само TCP ACK-тата са много, PUBREL и PUBREC май се казваха са чак накрая на тия 1Мбайт - ако го пращаш на един пакет. Ако го цепиш на парчета, и искаш ACK значи си намерил случай, в който голямо съобщение може и по-бързо да мине.
В случаите, когато връзката прекъсва често е ясно че разделянето на малки парчета повишава шанса да минат живи и здрави. То в тоя случай TCP-то би трябвало да може да се нагласи да върши същата работа - с по-големи таймаути и повече опити за повтаряне, подходящи размери на сегментите.
И всъщност какво е решението тоя мегабайт да се качи по-бързо през GPRS? Много ми е интересно.
А и е интересно защо се очаква да дропне при неочакван PUB? Ако клиента има бъг - ок, ма той и без външна намеса в тоя случай може да се взриви. Тука е интересно да се замислиш какво ще стане в "алтернативна" ситуация дето няма брокер да се грижи данните към теб да вървят гладко.

Edit: забравих последния въпрос - какво имаш предвид под "нормално" да го правя - кой протокол ще ми свърши работа и ще прекара 1мбайт надеждно през мрежа с по 1с латентност по-бързо?
Не отричам че в определени случаи е по-добре да се разцепи на по-малки парчета - но това не значи че мога с лека ръка да кажа "а, значи изобщо няма да поддържам по-големи". Протокол отгоре, т.е. примерно топик в който да идва парчето и друг в който да се потвърждава може да се направи и на приложно ниво без да трябва да се пуска FTP.
Замислих се за това с това да ни застрелят с входящо съобщение докато качваме нещо голямо - почти съм сигурен че брокера няма да пусне тоя изненадващ пуб ако вече сме започнали да качваме към него - просто няма как да сподели сокета в тоя момент? Ще изчака да свършим (ако сме QoS 0 да се източи размера, ако е QoS 1 или 2 да се разберем накрая с потвържденията) и тогава ще ни го пусне.
Ама нищо де, то не се прави така, има си други протоколи...


Нед Окт 29, 2017 12:24 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
gicho написа:
Миро, не знам какво твърдиш с това "директно отива към MQTT"

.....

И да, всичките минават през MQTT-то, както и през TCP-то.


Нед Окт 29, 2017 8:40 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Аха, да де, така е, но е валидно за всички протоколи - ако е на този "порт" отива "директно в http" - нали така?.
Нищо не пречи да има отделно http, ftp, или дори втори и трети mqtt сокет.
Т.е. разделението дали ще е към Mqtt, или не, идва от това по кой сокет идват данните. Също както се дели дали е за http, или ftp, или https. Няма драма - нищо не е "пачнато" в lwip че да ходи по някакъв специален начин само в mqtt.


Нед Окт 29, 2017 9:25 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: LWIP MQTT TCP flow control въпросче...
gicho тая седмица ако имам свободно време ще тествам мегабайт щото и на мен ми трябват 64 кБ
не че и сега не мога но ме мързи да пиша сендер за файла

правих го по HTTP поради ред други причини(нестабилен GPRS, HTML програмистите не могат да се справят, а и модула има HTTP FOTA)


ПС: единствено трябва да се съобрази таймаута на сокета в зависимост от броя на парчетата от файла...
друго за сега не се сещам за да не стане

_________________
main[-1u]={1};


Нед Окт 29, 2017 9:42 am
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Ако искаш да пращаш към модула ползвай mosquitto_pub с аргумент -f. Аз ползвам или него, или от python-ския hbmqtt- има подобен тул hbmqtt_pub.
Това имах предвид и аз - ако някого го стряска 256МБ, или дори 1МБ, да мисли за 64К - често на ембедед не можеш да си позволиш дори 64К непрекъснат буфер. А и като растат възможностите на устройството нарастват и нуждите. А дори и да можеш 64К примерно от хиипа влизаш в рискова ситуация малок-а да гръмне в определен момент понеже и друг си казал "айде бе, едно 64К парченце няма да навреди".
Принципният проблем е фрагментиран (последователен) достъп - ако на някого не му трябва, хубаво. Но когато потрябва си трябва и трябва да се реализира по веригата до крайния консуматор на данните в устройството - примерно файловата система, или устройство по-надолу по друг бъс.

Едит: ще взема да се оборудвам с някакво SIM и quectel китче да тествам през него (като връзка към интернет) за да натрупам и там резултати. Макар че потенциалните клиенти едва ли ще паднат под 3G.


Нед Окт 29, 2017 12:04 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Сеп 26, 2004 8:21 pm
Мнения: 27949
Местоположение: София
Мнение Re: LWIP MQTT TCP flow control въпросче...
..не беше за тук ..


Нед Окт 29, 2017 12:53 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
то и аз май не съм за тук, ама нали се бъзиках с gicho пък се оказа че и моят порт на lwip не е цвете...
Ще го оправя, ама исках да попитам някой виждал ли е читав порт за STM32?
Да не откривам топлата вода... аз имам някакви стари кюбове, но като ги гледам тях косата ми настръхва. Може да дръпна по-нови версии, ама доколкото ги познавам надали са си оправили бакиите. Тъй че по-скоро питам за читав lwip порт, а не за тоя от ST ;-)


Вто Окт 31, 2017 6:53 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 74 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5  Следваща

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 4 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни