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

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


Не е такава логиката... те се викат в момента в който има нови данни, а целта на стека и мрежата е това да става ПРЕДИ ти да си приключил с предишните...
Ако не ти харесва калбак интерфейса мини на сокет АПИ-то и там ще е по друг начин, освен ако не се окаже че и берклито не ти харесва ;-)


Сря Ное 01, 2017 12:17 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

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

гледам и Cyclone ... и там няма "мегабайт" реализация - пишат в ринг-буфера докато има място

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


Сря Ное 01, 2017 12:25 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

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

8)


Сря Ное 01, 2017 12:36 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Другите апи-та не са опция поради това че имат изисквания без да дават нещо повече от познат на някого интерфейс, а пък RAW-а си е съвсем ок и нямам забележки към него. Единственото предимство на по-стандартните е по-лесно портиране на стар код от голяма система. Това не е някакво предимство за мен в случая, даже е бонус да не се изкуши някой да портира анахронизми.
По-скоро имам забележки към описанието ти което твърди че колбек ще дойде ПРЕДИ - "преди" важи за събитията - прекъсвания например, които не че идват преди, ами са несинхронизирани към моето "сега", т.е. начало и край. Предполагам ще се съгласиш че "нещото" наречено колбек (първи и последващ) идва в момент, който по никакъв начин не зависи от мен, така че няма как да се каже "преди" или "след" ще дойде. От мен зависи филтър (при connect) който може в този момент да го пропусне по веригата нагоре. Т.е. дошло е "фрейм" събитие, то минава обработка и може да предизвика следващ евент. Веригата си е някаква в стека като към мен излиза другото събитие - "данни по сокет 1883" - това на изхода от тцп нивото.
От MQTT нивото логиката е същата - регистрирам "subscribe" и то вика посочения колбек. Нищо различно?
Имам предвид че си има съвсем базови принципи за асинхронни интерфейси и ако има някакви "допълнения" те са просто още едно ниво - което при теб му викаш "опашчица", в lwip са буферите и т.н. Ако определено асинхронно апи не е мислено/направено с идеята на тцп-то в който има прозорец за групиране на няколко викания в едната посока, за които се чака пакетно един отговор, няма как да работи коректно.
Но и това не ми е проблем, нито е на LWIP - при тях, както вече описах, имаш начин индиректно да зададеш прозорец като в един определен момент, на 3-ти колбек примерно, кажеш (върнеш) за refused. Това можеше да е още един метод с който примерно вътре в колбека да върнеш "взех ги" или "отказах ги", но няма нужда от него понеже има ретърн стойност за резултата от работата на колбека.
Т.е. всичко си го има, така че аз съм доволен. Не виждам какво не ви харесва - че lwip са решили да не слагат изрична стойност за "refused"?


Сря Ное 01, 2017 3:49 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
TheWizard написа:
а за колко време пишеш 1024 във "файла"

гледам и Cyclone ... и там няма "мегабайт" реализация - пишат в ринг-буфера докато има място

В момента данните не ходят във файлова система, да, пишат се в SPI флаш. Като скорост на запис сигурно не е над 100-200Кбайта/с - изпълнява се в далечна част от кода и не е с висок приоритет. Но това ми е добре дошло за да видя евентуални "дъждовни" дни вместо да се стрелкам 100байта пакетчета и да си свиркам.
В циклона мисля че се очакваше някой да празни от другата страна? В този сорс който аз ползвам също има рингбуфер за изцедените mqtt данни, но той също не помага - там си е написано даже като коментар:
Код:
/**
* Number of bytes in receive buffer, must be at least the size of the longest incoming topic + 8
*[b] If one wants to avoid fragmented incoming publish[/b], set length to max incoming topic length + max payload length + 8
*/

Но поне не са забравили че има и по-големи payload-и и са оставили вариант за фрагментиране.


Сря Ное 01, 2017 3:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Калбакът се вика когато се появят данни. Точка. А пък идеята на tcp прозореца е да има буфер, за да може мрежата да си работи ефективно без да се съобразява със скоростта на обработката на данните. Очевидно твоят проблем в тая тема е, че не смогваш да обработваш данните достатъчно бързо.
С кое дотук не си съгласен или не ти е ясно? Щото останалото е 100% следствие. Мрежата се опитва да праща до размера на прозореца и тъй като си бавен, съвсем нормално е буферите ти да НЕ са празни, т.е. всеки следващ калбак да идва ПРЕДИ ти да си приключил обработката на пакета от предишния. Ако ти беше доста по-бърз пакетите щяха да идват СЛЕД, ама не си...

Така че не ми обяснявай как "нещото" не зависило от теб. Съвсем пряко си зависи от теб и твоята скорост.
Аз разбирам, че на теб ти се иска след като си получил един калбак и не си го потвърдил, да не идва следващ докато не го потвърдиш. Не е редно така! Не забравяй, че пакетите са в буфер на стека. Не са в твоята памет и това е идеята. Целта е да се избегнат memcpy-та и да избегнеш нуждата от буфер при теб. Но за да се получи това, трябва да те викат на всеки получен пакет. Иначе представи си следната ситуация - искаш да ги запишеш данните на файл, ама секторът ти е 512 байта. От другата страна пък си нямат идея какво смяташ да правиш и ти пращат първи пакет от само 100 байта. Идва калбак, обаче ти нямаш материал за цял сектор. Не може да ги потвърдиш без да си ги записал, не можеш и да не ги потвърдиш щото няма да получиш повече калбаци. Кво праим, ъ?
Да не го дъвчем повече... харесва ти или не, тва е положението. Приеми че няма друг избор освен да получаваш калбаци. И не е редно да експериментираш с отказвания и други простотии. Виж стека, че в тая ситуация не се губят наистина, запазват се в refused_data, но малко по-нагоре имаш асерт дали вече нямаш запазени... Не ми се гледа нататък, а и един Бог знае какви ще са сорсовете в следващите версии. Не си залагай сам бомбички, пък ако искаш - залагай си ;-)


Сря Ное 01, 2017 5:21 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Та причината е че искам да постигна "zero copy" на данните от стека до крайния консуматор на идващите данни. Нека да ползваме примера когато идващите данни трябва да се запишат на диск, или файлова система, или каквото е удобно за размишление. Т.е. целта е функцията за запис на файловата система да се повика с поинтър към pbuf данните от стека, или да се модифицира/обвие така че да може да работи със списък от буфери или по-точно с API-то на pbuf.h


Сега, дали ще махнат поддържката на refused, или ще махнат нещо друго от апи-то аз не мога да контролирам. Да, ако ползвам по-малко неща от апи-то статистически по-рядко ще има нужда да пренаписвам, съгласен съм.
Да приемем че съм сигласен с това да не ползвам refused - и това ми е решение 1 което бях направил в началото. Та да уточня за решение 1:
- съгласен съм да получавам много колбеци (на всеки пакет) дори да не съм потвърдил с tcp_recved() (и няма да ги рефюзвам)
- щом съм съгласен с горното значи съм готов да приема безропотно данни - до определен обем - конвенцията там казва това да е = TCP_WND, и няма да refuse-вам стига да не нарушат конвенцията да няма повече данни от TCP_WND (те го спазват, нямам претенции)
Като следствие, ВСЕКИ клиент на TCP стека е длъжен да спазва тази конвенция и то точно до TCP_WND константата. Съгласни ли сме с тия твърдения?
Сега поглеждаме че всичко работи но идваме до извода че, повтарям, "ВСЕКИ клиент на TCP стека е длъжен да спазва тази конвенция и то точно до TCP_WND константата".
Ако искаме спираме дотук и всичко е ОК. Ако ни притеснява извода от горния ред можем да потърсим решение?
Оттук насетне пиша за хората, които имат желание/нужда/интерес да мислят върху това как може да се махне и това последно ограничение. Който не го смята за проблем не очаквам да го мисли. Добавям че много добре би се приело ако успеем да сложим ключова дума "zero copy" като екстра от нашата работа по-нататък.
Та какви са възможните решения, които съм видял и може би неправилно съм опитал да дискутирам тук:
- да се поддържа различен размер за всяка конекция - онова SO_RCVBUF което го има на големите стекове - Миро спомена посока в стека с която да се реши това; отделно е обсъждано и може и да се появи е вдин момент в оригинала на lwip; това най-смислено би значело да може по всяко време (не само при отваряне) да може да сменя размера на джама
- да лимитираме TCP_WND до абсолютен минимум (1?) така че да сме спокойни че всички ще задоволят това ограничение лесно
- или да се намери начин буферът за един джам да остане в стека и механизмът за преточване на данните от този буфер към приложението да позволява пакетите които пълнят един джам да останат в този буфер и да се източват полека, асинхронно, нагоре - т.е. на малки парчета, пък били то и по 2 байта
Това последното ми прилича много на механизмите в големите ОС-ове където клиента се очаква в произволен момент да каже "read" и да каже "ама само 2 байта че толкова очаквам да е хедъра и в него ще видя колко ще е целия пакет, и после ще повикам read с колкото още мога да асимилирам". Т.е. тъпкането от тцп в буфера на съответния сокет е когато дойдат данни отгоре, ack-тата са когато прецени че има освободено място (което е поради събитието read от другата страна и се предава като информация към тцп под формата на уведомление че се е отворило място в иначе пълния досега буфер). Четенето е бавно и зависи само от скоростта на четящия тред който пише на диска.
Синхронизацията пак става по това кога четящия засмуче данни, и това диктува скоростта на тцп връзката.

Като цяло и двете идват да покажат че както и да се въртим, буфер с размера на един джам си трябва (изключвам частни случаи когато четящия не прави нищо с данните, или си е наложил сам ограничението да обменя бавно, т.е. е вградил лимит на скоростта в предаващото ПЦ примерно).
Ако това е вярно остава да се разбере дали може да се получи на ниво TCP - т.е. дали можем да го постигнем използвайки буферите на стека. Защо държа да е там? Защото данните вече са изкопирани от фифо-то на MAC-а, най-често с DMA, и не искам повече копирания (zero copy гоня). Всяко едно местене в друг буфер и освобождаване на pbuf-рите на стека значи още време за копиране. Т.е. ако гоня да освободя pbuf-рите значи задължително трябва да копирам някъде (цикличен буфер, ...) който да е per-connection и отгоре помним изискването да е поне TCP_WND размер.
Ако искам да постигна zero copy значи търсим механизъм който да позволи консумиращия тред (оня дето пише във файл примерно) да получи директно данните от pbuf-а. Иначе не е zero copy.
Допълните ще трябва и обратната информация която освобождава pbuf-рите и праща ack.

Та, е ли възможно, според вас, това да се постигне с lwip или трябват твърде много промени? Посоката в която гледа е с онова refused което има наченки да прави нещо подобно.
Питам със знанието че не съм задълбавал толкова дълбоко и се надявам някой да каже "не може щото еди какво си", а отговори "така не се прави" би трябвало да значат да търся друг (комерсиален може би) стек който дава "zero copy" в брошурата си.


Чет Ное 02, 2017 11:39 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

За съжаление аз продължавам да не разбирам какъв точно ти е проблемът. Казах ти - сложи една опашка. При мен мисля беше с фиксиран размер от 20 указателя, демек 80 байта. Не ми казвай че са ти проблем, след като си сложил колко бяха - 8 пакета за джам? Демек ти имаш конфигурация дето заделя над 10К буфери на връзка, а сега търсиш как да спестиш 0.1К за управлението им...
Не вдявам, честно!


Чет Ное 02, 2017 5:38 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Не са проблем, разбира се.
Искаш да помня указателите към pbuf-ите които ми е давал стека през времето през което не ми е било разрешено да препращам данните? Т.е. когато флоу контрола към файловата система е казал спри? Това са "ония моменти" дето мислех да ги цакам "refused".
Това е ок, така ще изградя върволица от пакети, които реално си стоят в буферите на стека (консумират от бройката pbuf и трябва да увелича там размерността - ако се наложи). Когато ме отпушат от другия край трябва да почна да вадя от върволицата и да празня тия буфери - това също е горе-долу ОК, с уговорката че влизам в ситуацията ако пакета е бил последен за джама или въобще да няма повече колбеци, но то все ще дойде моето събитие за отпушване от към приложението и там ще извадя следващото.
Съответно tcp_recved трябва да вкарам в упражнението също - не може да е директно във всеки колбек безусловно. Ако е чак след асинхронния отговор (на "файловата система" - след 100мс) дали ще се укажа в ситуацията да нямам данни за известно време - докато излезе ACK-то и другата страна се накани да предава към мен? Би трябвало тоя механизъм да сработи още преди това, т.е. като се е отворило малко място, т.е. съм обработил примерно 2 от 10-те pbuf в опашката, да дам tcp_recved() за да се възстанови трансфера? Но тук стека трябва да удари едно рамо - трябва да ъпдейтне джама и да го намали - от началните примерно 10 пакета до актуалните 2 (щото толкова място съм освободил). Тука нещо ми се губи къде ще е подходящото място за tcp_recved...
Струва ми се че нещо ми убягва - реално приложението ("файловата система") може да ми отговори на парчета - аз съм и дал да пише 1К, тя или ще ми отговори накрая, или ще трябва да мисля междинни отговори в които да казва колко от тия 1К е усвоила. Това е много подобно на tcp_recved() което има аргумент за размера на обработените данни.
Затова ми намирисва че нещо пропускам - не може tcp_recved() да е мислена с аргумент за размер, и на мен отделно да ми се налага да правя същото паралелно - трябва да има начин да използвам механизмите на lwip и tcp_recved. Най-лесният от логическа гледна точка е това което бях направил в началото - да приема че ми трябва буфер поне един джам и да правя tcp_recved когато го обработя. Или вместо мой буфер да ползвам тая опашка от поинтъри към pbuf-ове без да ги копирам и вадя в междинен буфер.
Ще пробвам да разиграя това с опашката от pbuf като начало и да видя дали ще открия къде да сложе recved и останалите дреболии като pbuf_free.
Всъщност трябва да огледам самата имплементация - нали pbuf са свързани списъци, дали стека не може да "помни опашчицата" вместо мен? Т.е. на следващия колбек да ми даде pbuf които свързва повече буфери, ако не ги хапна, на по-следващия още по-дълъг списък? Като гледах че са списъци първо това ми хрумна че са направили - ще гледам по-дълбочко. То може да е част от веригата refused, ама обещах да не говоря за нея :-)

Мерси за идеите, ще пиша дали съм успял или съм хванал лесния път...


Чет Ное 02, 2017 9:41 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: LWIP MQTT TCP flow control въпросче...
MQTT message callback получава един цял готов пакет с дължина колкото е в хидъра на пакета...
ще правиш някакъв специален колбак с детектор за "голям" пакет щото освен по пакет сайз няма как да разбереш че идва... голямата мотика?

ps: всъщност можеш да маркираш message с флаг retain OR dup и да разбере дивайса че идва "файл"
иииии си реших проблема с криптиране на app level обаче само в посока на девайса което ми върши перфектна рабта :)

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


Чет Ное 02, 2017 10:15 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

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


Въртиш, сучеш и все търсиш някой друг да ти върши черната работа... Опасен си!

Може и да може, ама не е добре! За да не обработиш данните, които калбака ти дава значи си имал някаква причина. Ако причината е в мрежата, да кажем дават ти по-малко данни. отколкото ти трябват, то тогава може да мислиш в любимата ти посока как да рефюзваш и да чакаш следващ калбак. Но това е много нестандартна ситуация. В общия случай причината да не преглътнеш данните не е по вина на мрежата (всъщност тя никога не е, щото няма ограничение колко най-малко данни да получаваш). Та обикновено не искаш данните щото не си готов, но когато станеш готов е добре данните да са при теб. Иначе ква файда че си готов като нямаш данни.
Другата причина да се прави с опашка е, че обикновено имаш някаква обработка и освен ако не си супер бърз (а ти май не си) е желателно да си обработваш данните в твой си контекст а не в контекста на мрежата. Демек имаш две нишки, твоя и на стека. И ти трябва синхронизация между двете. Т.е. трябва ти опашка или нещо дето върши същата работа...

Относно потвърждаването... Ти си преценяваш дали да потвърждаваш част или всичко на куп. По-важно е, че потвърждението е редно да го правиш от контекста на мрежата, а не от твоя контекст. Демек имаш още една синхронизация, но тоя път в обратна посока. И не съм 100% сигурен но почти съм сигурен, че по време на потвърждението стека може да освободи някой сегмент щото те са точно списък както знаеш. Това ще рече че докато не мине потвърждението не е много редно да се разхождаш из тоя списък. А това ще рече че евентуално частично потвърждение яко ще ти разкаже играта... Аз го правя между другото, но при мен е различно (нямам zero copy).
Освен това не виждам голяма файда да потвърждаваш парченца. Така ще се увеличи броя на ACК-тата, ще почнеш да получваш малки пакетчета... Може и да има ситуации в които да се налага това, но май в повечето случаи само ще накъсаш трансферите излишно. Обработи си целия пакет/сегмент и не се вкарвай във филми...


Чет Ное 02, 2017 11:02 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
За контекста няма грижи - всичко по lwip върви в един единствен тред, вкл. mqtt обработката. Получените данни като парче от mqtt payload се пращат навън асинхронно през съобщение и се обработват там от друг тред ("файловата система"). Та обратно също - файловата праща съобщение и в контекста на lwip треда то се обработва и води до викане на api на стека (примерно tcp_recved). Също и таймаутите на стека (sys_timeout) се клатят от тоя тред, така че и те не мога да доведат до конфликти. Да, и пакетите от драйвера идват през съобщения пак в този тред. Дали не е много работа за един тред и дали да се сцепи на повече е отделен въпрос. Ако има нужда то тя би била по-скоро там където се преминава на горно ниво според OSI, но в lwip не го правят вътрешно, и то с право според мен. Така че и аз за момента не съм отцепил tcp-то примерно да изхвърля през мейлбоксове а mqtt да чака в друг тред.
А "мързела" ми идва от това че не виждам смисъл да правя нещо, ако то е предвидено и направено - освен време за разработка това иска време за тестване, за поддръжка. Ако съм ларж да си пиша и стека от нулата... Или имаш предвид че теб тормозя да поясняваш? Щото представи си че възникне някакъв код от дискусията тука и го пратим гордо на авторите на стека - не би ми се искало да чуя "за чий го правите като pbuf-а е направен за това?". Е, то сигурно най-добре с тях да се обсъждат подобни промени, но другото си е да поспорим на родния език.
По-неприятното е че ми се струва че това си е общ проблем - на всички консуматори на tcp данни, независимо от конкретния по-горен протокол. Е, не на всички, тия дето се ограничават на един пакет най-много няма да им трябва.
Но ако е идентифициран общ "проблем" си мисля че е по-добре да гоним универсално решение, което да е разширение на апи-то - за да може лесно да се преизползва от мен в други системи, или за други задачи, а защо не и не само при мен. Ако го обсъждам е за да видя и друга гледна точка - ако решението към което драпам е силно недолюбвано от специалисти в областта, ще мисля още. Стига да не говорим за субективни неща и чувства.
Та логически това ми мяза на разширение на интерфейса от tcp нивото нагоре - следователно не бива да е mqtt-специфично, а универсално за всичко на нивото на mqtt - app дето му викат в lwip папките.
За опашчица от поинтъри няма проблем, но ако стане за буфер голям или подобно, защо да разхищавам памет, ако вече някъде се пази това същото? Това не пасва и на zero copy целта.

Едит: да, няма да правя потвърждаване на парченца - клиентите на данните не го поддържат и не виждам да го направят близките две петилетки, отделно си е усложняване. Но принципно има смисъл - поне по аналогия с фифо-тата на перифериите в контролерите(прекъсване на watermark ниво - полу-празно/пълно, или на точно граница) или дори самото TCP. Ако приема че вътрешните ми латентности за прехвърляне на парчетата са незначителни в сравнение с тези на TCP ниво може спокойно да се остави за много далечна оптимизация.


Чет Ное 02, 2017 11:25 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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


Караш ме да обяснявам едно и също нещо 10 пъти... това с опашчицата го дъвчем вече няколко страници. Ако знаех друго решение да съм го казал досега. Стекът може и да позволява нещо, но аз не го познавам а и не мисля че е правилна посока...

Цитат:
За опашчица от поинтъри няма проблем, но ако стане за буфер голям или подобно, защо да разхищавам памет, ако вече някъде се пази това същото? Това не пасва и на zero copy целта.

Логически е редно данните от калбака винаги да се вземат и да се трупат като "чакащи за обработка". Дали ще направиш както ти казвам опашчица за указатели към списъци или ще ги пренавързваш в един общ списък си е твой проблем.
Но в общия случай опашката е по-доброто решение, защото:
1) Опашката позволява асинхронна обработка. По всяко време може да пъхаш от едната страна и да вадиш от другата. В общия случай това се прави в различни нишки и с опашка нямаш грижи. Докато ако вместо опашка използваш списъка на pbuf-четата ще е много забавно как две нишки ще променят едновременно един и същ списък... Фън!
2) Като време/код пъхането в опашка е много по-малко от преправяне на списък.
3) Теб ти дават const данни в някаква форма. Някак си е по-редно да третираш всичко като const - и данните и указателите и да не ги преформатираш.


Пет Ное 03, 2017 1:46 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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


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

Кой е на линия

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


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

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