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

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
Коя част ти трябва - интерфейса към адаптера/хардуера или към ОС, или всичко? Не че имам какво да ти предложа в момента, но много усилия хвърлят по esp-тата.
Другото което мисля че трябва да е на ниво е порта на Broadcom/Cypress за WICED. Те всъщност там точно STM32 и atmel ползват като опция.
Друго в тая посока е mbed порта, там мисля че е към cmsis rtos.
А за драйвера за интерфейса намерих добра колекция от CycloneTCP стека.


Вто Окт 31, 2017 8:43 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
Моята каша е с буферите, то не е точно каша и май не моя... Мисля че е останало от луминари. С две думи буферирането е разделено на две, грубо казано L1 статичен кеш и L2 динамичен. Нормално минава само с L1, т.е. не яде много памет. Ако се позадръсти му позволявам до 20-на пакета в L2. Като L2 е според къде е алокейтнат съответния pbuf, т.е. зависи от типа, но обикновено е динамична памет. Цялата работа е, че ако не работи PHY-то няма механизъм за изхвърляне на кешираните пакети и ми яде динамичната памет безсмислено...
Но имам и други проблеми, примерно покрай прекъсванията на PHY-то и т.н. Та с две думи трябва ми портването от към хардуера MAC/PHY.
Иначе кюба днес го гледах и ревах... Буквално! Не знам дали щото ми слагаха капки за разширяване на зениците или заради кода им, ама май е второто... Така или иначе нещата там са плачевни. Ти може ли при прекъсване от PHY-то, т.е. в контекста на EXTI прекъсването да викаш четене на PHY регистри. То бива, бива, ама чак пък толкоз!


Вто Окт 31, 2017 9:41 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
СТМ библиотеките съм си забранил да ги поглеждам, дори ако съм приел достатъчно "гориво" да гледам с розовите очила... Алокации в прекъсвания, изобщо срам, срам. Язък за не лошите процесорчета.
Със сигурност не мога да вникна в проблема ти, но все пак - фи-то дава събития/прекъсвания при смяна на статуса, предполагам оттам имаш точка за започнеш прочистването нагоре? Или имаш предвид че някъде нагоре това "чистене" не може да замахне добре?
Погледни CycloneTCP-то - има му сорса, ама си дръпни архива GPL - https://www.oryx-embedded.com/download/CycloneTCP_SSL_Crypto_Open_1_7_8.zip
Не съм гледал за стм точно, гледах за един инфинеон и един тексасец - погледа беше и за тях диагонален, но поне не ми изгоряха очите както с стм-ския код.


Вто Окт 31, 2017 10:35 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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


Вто Окт 31, 2017 10:43 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
Да, PHY-то може да прави прекъсване (макар че при някои IRQ пина е шернат с друга функция) при смяна на линк статуса и т.н.
Та в зависимост от линк статуса може да се спират/пускат някои дейности като да кажем DHCP-то. Няма смисъл да се мъчи горкото и да ми заема памет за пакети при условия че няма линк. Ще ми се и ARP-то да го спра, щото забелязах че и то се пробва да предава. Но не знам то дали може да спира изобщо.
Та за да не откривам топлата вода искам да видя идеи какво се спира/пуска, какво се чисти... колко големи да са буферите и т.н. Иначе аз трябва да обмисля всички ситуации и да пробвам, ама това изисква време.... пък и мразим да мислим ;-)
Тъй де, утре ще хвърля едно око на циклона, макар че то техния стек сигурно ще е различен... Сега се сетих че някои от RTOS-четата ползваха lwip, ще им фърля един винтилатор.


Вто Окт 31, 2017 11:15 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Това не го знам... ама ти още ли не си оправил хендшейка? Защо ти е да променяш джамците... Оправи го оня калбак, не потвърждавай пакетите докато не ги обработиш и хендшейка ще бачка - гаранция! ;-)


Вто Окт 31, 2017 11:20 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
По моите разбирания виндоуът идва да покаже колко данни може да "поеме" (буферира) определена връзка(win/unix/bsd), или всяка връзка (LWIP). Логиката ми е че след като знам че в определен път в системата (т.е. определен сокет) имам еди колко си буфер (без значение на кое ниво, може да е чак в app, може да е между app-а и mqtt-то, или между апп-a и хттп-to), то за да накарам оттатъчния да спре да бълва данни (които за него може да са "скромните" 64К, а аз да съм на процесор с 64К общо) трябва да укажа, или достигна до "верния" джам, съизмерим с буферите.
И тъй като ACK-то на TCP-то идва от tcp_recved() функцията, с която мога да кажа "дай още", то още преди да се стигне до това tcp-нивото трябва да се поуспокоило и двамата да знаят че сега чакаме единия да се наконти и да каже "Хоп" че другия да избълва пак.
Общо взето работата е само до първите пакети - т.е. ако TCP_WND е сложен на 64К примерно от колега, който е лапнал 64К буфер при него и му пее сърцето, то аз ако имам примерно 4К (да кажем като междинен буфер, или буфер на уарта който печата данните, или буфер на файловата система), то тези 64К в началото ми разказват играта. Стекът си стреля колбеци N пъти без да чака tcp_recved() след всеки един от тях - т.е. там не мога да забавя данните - няма какво да извикам, освен да му блокирам в колбека :evil: и да ходя да садя домати на село.
Реално стигам до извода, който може и да е грешен, че конвенцията (контракта) на интерфейса на RAW API-то е следната:
- при билд имаме даден TCP_WND define, той важи за ВСЯКА tcp връзка, не може да се задава идивидуално
- при установяване на връзка джама се инициализира да е равен на TCP_WND
- когато дойдат данни стека ще вика recv callback за всяко получено парче, т.е. фрейм (1500 байта) за да ги предаде на приложението -
- стека може да повика толкова броя recv callback-а колкото са нужни за да "изхвърли"/"да се освободи" от данни в размер на макс един джам - т.е. в началото приложението трябва да е готово безропотно да приеме TCP_WND броя байта за отрицателно време
- стека няма да вика повече от TCP_WND количество данни, или евентуално по-късно променения в процеса на работа джам - не че нещо, ами просто другата страна ще е спряла да праща поради липсата на ACK
- стека НЯМА да чака след всеки колбек да има по един tcp_recved()
- стека очаква приложението да извика tcp_recved() когато приложението прецени че има място/възможност да поема още колбеци

Това ме навежда на мисълта че ако мога да сложа TCP_WND поотделно за отделните конекции ще мога да укажа какво количество данни могат да бъдат поети е даденото "направление".

А за фи-то виж популярните портове - може би за esp8266/32, или mbed.


Сря Ное 01, 2017 8:28 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
Ся, TCP_WND по подразбиране е на абсолютния минимум от 2 пакета. По-малко от това нема накъде, щото заминава всякаква възможност за конвейр. Ще трябва пакет по пакет да ти пращат и да чакат ACK на всеки пакет преди да могат да пратят следващ. Това е супер тъпо дори за малък трафик, да не говорим за твоите мегабайтови мераци...
Пак ти казвам, проблемът ти не е в размера на джама. Без значение колко е голям джама, ти ако потвърждаваш в калбака, скоростта ще е толкова колкото може да мине през жицата и стека ти. Ако искаш да не идват повече данни, отколкото ти може да обработваш решението е само да забавиш потвърждението и нищо друго.

Иначе, да TCP_WND важи за всеки сокет... не може индивидуално, но и да можеше реално ти можеш само да го вдигаш. Като гледам не е сложно да се направи. В tcp_pcb структурата трябва да сложиш rcv_wnd_max поле по същия начин както има snd_wnd_max. И навсякъде където се сравнява с TCP_WND трябва да сложиш да се сравнява с rcv_wnd_max. Естествено и да инициализараш полето при създаване на връзката. Но пак да повторя това би имало смисъл ако работиш с много сокети и искаш да вдигнеш джама само на определени. Ти нито имаш много връзки, нито искаш да вдигаш....


Сря Ное 01, 2017 9:07 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Тука или нещо не разбирам, или има нещо грешно: при мен TCP_WND е сложен на 8 MSS-а. Идва така понеже стар софтуер (http) го е искал и е сложен на толкова - мога да го намаля и така си решавам проблема, но е ясно че някой друг ще реве - не случайно го е вдигнал. Това е дето казваш че нямам други сокети - в момента в софтуера има, а и не мисля да се меся на другите - това се очаква да е "естествен подбор" и ако mqtt може да поеме нуждите http-то ще изчезне.
Та, ако потвърдя с колбека не само че няма да забавя нищо, ами даже ще го забързам? В момента НЕ потвърждавам в колбека и въпреки това ми стреля много колбеци докато си изпразни TCP_WND размера - последно гледах че ми захвърля около 8К под формата на няколко колбека. Още на първия хвърлям колкото има данни към обработващия таск, но той е бавен, така че след известно време (десетки-стотици ms) ми връща обратно информация че е готов с тия данни (първите). Та аз tcp_recved го викам СЛЕД тези 100мс, но това не влияе на стека - той си ме застрелва с данни още първите няколко мс под формата на няколко колбека. Поне това е поведението което наблюдавам. Размерът, след който спира "стрелбата" по мен е колкото е TCP_WND размера.
Не виждам начин по TCP API-то (RAW) да му откажа, забавя, или каквото и да е друго за да няма "твърде много" колбеци. - ГРЕШКА (що няма strikethrough в тоя редактор?)
И ТУКА ИЗГЛЕЖДА че недоглеждането е мое - сега гледам какво очаква стека като return от моя (по-точно на mqtt)-то колбек - и там ако е различно от ERR_OK (ама да не е ERR_ABRT) он (стека) ще БУФЕРИРА... Гледам че има някяква обработка на refused_data и ще търся дали може да се справи.
Ще пробвам да спра "потока" от фреймове към mqtt-то, т.е. ще прекъсна белтъка между тцп и mqtt докато вътрешния ми флоу контрол не ми позволи да тичам пак - мисля направо да подменям временно tcp_recv колбека с такъв който винаги (с таймаут) връща "не мога сега", и като ми се отпуши вътрешния канал да върна mqtt-шкия колбек - така ще стане излишен и пач-а ми за по-късен tcp_recved().


Сря Ное 01, 2017 10:16 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Значи в тоя калбак дето си сложил на първа страница имаш:
gicho написа:
Код:
static err_t
mqtt_tcp_recv_cb(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)
{
  mqtt_client_t *client = (mqtt_client_t *)arg;

    /* Tell remote that data has been received */
    tcp_recved(pcb, p->tot_len); //Ето къде даваме ack на tcp

   .....

}



Демек както сам си си го коментирал, още като получиш пакет и даже преди да си го обработил го потвърждаваш.... От тук нататък няма какво да коментираме. При първа възможност стека ще прати ACK и другата страна ще продължи да праща и ще ти идват калбаци до откат...

Сега, що се касае до началото... след като си сложил 8 максимални пакета като размер на джама, естествено другата страна ще изстреля 8 пакета и при теб ще цъфнат 8 калбака без да си потвърждавал нищо. Нормално и така трябва да бъде. Не съм гледал ако върнеш грешка на калбака дали ще кешира, щото така или иначе не е редно да връщаш безпричинно грешки. Клабакът трябва да се пръкне когато има пакет, това му е работа. Твоята работа е да запомниш някъде че имаш чакащ пакет (казах ти за опашчица) и да излезеш. Когато пък извадиш от опашката и обработиш пакетче трябва да извикаш tcp_received(), за да се плъзне джама...
Идеята на джамовете е когато ти си по-бавната страна, винаги да имаш готови и чакащи данни, за да не се налага да спираш и без друго бавната ти обработка. Не виждам какво те притесняват калбаците, тяхната задача е да се пръкват точно *ПРЕДИ* ти да си приключил с обработката на предишните данни. Това означава че всичко е ОК. Да не искаш да ти идват калбаци е безумие, значи нещо имаш сбъркано с идеята за tcp стриймовете.... Не знам какъв ти е проблемът ;-)

По въпроса с размера.... 8 пакета сякаш е прекалено за малък контролер. Значи слага се голям прозорец ако си на компютър, имаш бол памет и тежък ОС, в който едно приложение дето точи нещо от мрежата може дълго време да не получи управление. Съответно за да не спира трафика се буферира в прозореца, а когато приложението получи управление то набързо да може да опраска няколко мегабайта. В твоя случай обаче 10-15К да седят и да те чакат няма голям смисъл. Не си чак толкова бърз и не си с ОС, а с РТОС, така че и 3-4К са достатъчни. Ти докато ги смелиш ще дойдат следващите от мрежата. Не забравяй че като ползваш 8 пакета джам на всеки сокет трябва да имаш толкова по броя на едновременно отворените сокети като размер на входния буфер. Примерно ако сложиш че ще поддържаш 4 сокета стават 32 пакета по 1400-1500 байта receive buffer който трябва да имаш.... Отде намираш толкоз RAM ;-)


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

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: LWIP MQTT TCP flow control въпросче...
нящо много го задълбахте тва
MQTT за сенд пакет/процедура ползва таймаут дефиниран пример 1 секунда, ако са много N пакетчета за целия пакет(мегабайт) ... N секунди тайм аут... TCP-то само ще си го прати целия буфер, парче по парче

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


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

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: LWIP MQTT TCP flow control въпросче...
общо взето май няма чист начин горното ниво да влияе на долното. извън концепцията е.
пък и ключовите думи в LWIP са 'LW', демек - реализацията на стека е много въздухарска и не би трябвало да се очаква, че ще се справи с повече от 10% от нещата, които прави пълноразмерен стек на машина с почти безкрайна памет.

MQTT може ли да върви по UDP?
в такъв случай поне има механизъм отговорността за ACK да се носи от приложното ниво, а не от стека.

друго, което се сещам, е да ползвате slow start механизъма в сървъра.
примерно сетвате slowstart_flightsize (това е броя на пекети в полет без ACK) на 1 и сървъра ше ви ръси само по един пакет, докато не му върнеш ACK. виж какво ще се получи, не съм много сигурен в резултата между стекове от различна категория.
пък и си остава проблема за дуалността ACK от долното ниво и горното

---

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

фърли едно око и на PAWS в RFC1323.


Сря Ное 01, 2017 11:41 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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


Сря Ное 01, 2017 11:56 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: LWIP MQTT TCP flow control въпросче...
РАМ тука има, но това е само една от системите на които ще върви тоя софтуер, така че не се разполагам много.
Онова от кода е нещото което съм махнал за да мога да изместя викането на tcp_recved() по-късно, но то помага да се забави трансфера оставайки на парцали по TCP_WND, което води до това че както каза, трябва да се буферира (казваш "опашчица") до ... TCP_WND размера. Т.е. при глобален TCP_WND всички "опашчици" трябва да са готови да поемат по един TCP_WND, и то ако правилно работят с tcp_recved за да не им дойде втори TCP_WND. Тук не споря, а и не виждам да има разминаване - просто уточняват че дестинацията трябва да може да поеме, или да има преди нея някой който може да буферира ("опашчица") един джам. Това налага балансиране на TCP_WND с противоречиви изисквания на различните дестинации. А те може да се десетки - няколко различни mqtt абоната в системата (слушащи на различни топици), няколко вида http заявки, FTP към различни дестинации - RAM файлова система, SPI флаш, СД карта, ... Затова отвориш дума за джам за всяка конекция.
А колбеците се очаква да идва точно СЛЕД като съм информирал че предишните данни са приключени, т.е. буфера е свободен. Идването от мрежата е бързо като bandwidth, но трябва да борим латентностите, заради което си го има window-а - затова трябва да има запас от данни "някъде" преди мен, но той да е запас - т.е. да чака да се освободя. Така изглежда имплементацията на механизма с връщането на err от колбека. Реално не връщам "грешка", просто ретърн енум-а няма отделна стойност за refused и ползват всичко което е различно от ОК или ABRT. Този механизъм прави точно каквото ми е нужно на мен, а и каквото им трябва на тях - аз не ги спирам да ми викат колбек, но ползвам техния буфер за да кажа "стоп - не мога повече". Това си е ок понеже и към мен трябва да има флоу контрол.
Това ще доведе до консумация на буфери в стека, за да ми пази моите данни. Но аз ползвам негова услуга, която не бях видял преди, за да ми свърши работа по буферирането. Мисля си го че е ОК защото решава проблема с общата дефиниция за TCP_WND. В случая ще трябва да съобразя броя буфери (увелича) за да не се "срамувам" да му искам тая услуга. Ако не работя пък той ще е на плюс щото съм му дал буфери.

Направих бърза проба на това с err връщане от колбека и работи - сега ще огледам шарковете дали няма притеснителни времена. Но пакета си остава в буфера в стека и идва по-късно - сега ще видя кога идва, дали не е на някой таймаут. Не че е лошо, просто тик-а на стека съм го разредил доста и може да иска "забързване".

Дедо, по UDP може вариант (разширение) наречено mqtt-sn. Но то TCP-то става лесно UDP като му забиеш джам от 1? Тогава реално горното ниво има контрол върху тцп трансфера с грануларност 1 пакет. А по UDP ще стане с размери на публикации от 1 пакет, което и по TCP не прави никакви проблеми. Лошото става когато искаш "да поддържаш" (не казвам да ползваш) големи размери. Борбата с рутерите се надявам да ми се размине заради TCP-то - ако тръгна на UDP ще трябва да потвърждавам на приложно ниво през 10 хопа по 50мс примерно и ще стане леееко лагаво.

Визард, то с "пращането" няма проблем - за пращащата страна. Флоу контрола не се прави за да свърши работа на пращащата страна, а за да улесни приемащата. Той изпращача ако има лимит (щото бавно чете от диска) ще си праща бавно и на никого не му дреме. Все едно да знаеш колко силно да отвориш крана на чешмата без да гледаш колко е тясна тръбата, и да се надяваш да не прелее. А това че макса на чешмата би твърде малък за да напълни маркуча отдолу - ми макса е този на чешмата. Таймаутите от една страна ги има на ниво ТЦП, и те са важни понеже само той следи отделните сегменти и времето между тях. От друга страна на ниво приложение може да има други - но те не могат да заменят тези на тцп-то, евентуално могат да ги допълнят. Макар че ако имаш гъвкав достъп до таймаутите на тцп-то нямаш нужда от друго (евентуално ако се притесняваш от бъгове в стека).
Но за да стане "TCP-то само ще си го прати целия буфер, парче по парче" трябва да му работят механизмите - потвърждения, ретрансмити, таймаути. Това се мъча да интегрирам в цялата картинка.


Сря Ное 01, 2017 11:59 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: LWIP MQTT TCP flow control въпросче...
gicho написа:
Идването от мрежата е бързо като bandwidth, но трябва да борим латентностите, заради което си го има window-а - затова трябва да има запас от данни "някъде" преди мен, но той да е запас - т.е. да чака да се освободя. Така изглежда имплементацията на механизма с връщането на err от колбека. Реално не връщам "грешка", просто ретърн енум-а няма отделна стойност за refused и ползват всичко което е различно от ОК или ABRT.


Да, трябва да има буфер но то си го има в lwip-то. От теб не се изисква да буферираш данни, нито да връщаш грешки. Под опашчица разбирай да запомниш указателя дето ти го дава калбака. Само указателя, не целия пакет. Така веднага като ти си готов с едните данни вадиш от опашката следващия указател (ако има) без да трябва пак да питаш стека (което отнема време ако е в друга нишка, а то е редно да е в друга).


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

Кой е на линия

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


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

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