Изпечатай

[BRADATA]

Що да не ти върши работа? Качваш сървъра на виртуална машина (или правиш една и качваш един линукс да играе рутер), прекарваш нетя през линукския рутер и си готов

[laskov]

Всичко над 20 е premium опция Това е платен абонамент, чрез който се самоиздържа иначе безплатната услуга, която предлагам.

Ами в такъв случай защо трябва да решаваш този проблем? На практика имаш неочакван помощник, стимулиращ клиентите да минат на платена услуга

[Breakfist]

Що да не ти върши работа? Качваш сървъра на виртуална машина (или правиш една и качваш един линукс да играе рутер), прекарваш нетя през линукския рутер и си готов

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

Всичко над 20 е premium опция Това е платен абонамент, чрез който се самоиздържа иначе безплатната услуга, която предлагам.

Ами в такъв случай защо трябва да решаваш този проблем? На практика имаш неочакван помощник, стимулиращ клиентите да минат на платена услуга

Аз мога и да ги отрежа тотално и да го направя с платен достъп, но не това ми е целта
Предлагам 20 безплатни свързвания, и търся начин да мога да ги осигуря на потребителите си. Пък който иска да вземе premium - да заповяда, но държа това да бъде въпрос на избор, не да ги задължавам един вид

[BRADATA]

Още по-добре - взимаш си още един ВПС и си правиш рутера там Хостинг провайдера ти има начин да ти направи вътрешна мрежа между машините...

[sudo]

Още по-добре - взимаш си още един ВПС и си правиш рутера там Хостинг провайдера ти има начин да ти направи вътрешна мрежа между машините...

Ехеее чак от такива изпълнения няма нужда
Аз бих развил идеята доста по-просто:
1. Казваш на приложението си да слуша на lo0
2. Правиш си Policy routing - ето  линк http://en.wikipedia.org/wiki/Policy-based_routing
с две думи: дефинираш кои входящи пакети са за твоята програма и ги рутираш към lo0 - тук малко NAT трябва да направиш, което ме навежда на мисълта, че може и само с DNAT да стане, но така или иначе идеята е че вече имаш рутер който хвърля пакетите м/у eth0 и lo0 и се надяваш тази програма cutter да ти свърши работа

Успех.

[BRADATA]

Ето за това са форумите Понякога човек се задълбава без да се огледа за по-простото решение

[gat3way]

За да опростим още повече нещата, може би е достатъчно просто да се пусне едно haproxy пред сървъра и да му се настроят въпросните таймаути и ограничения.

[Breakfist]

Може би по-скоро ще търся в такъв случай вариант да "убивам" връзките от страна на потребителя.
Лошото е, че зависват като "TIME_WAIT" и PID 0, дефакто не виждам кой процес трябва да прекратя, за да ги освободя.. Кофти работа.

[gat3way]

Ама то TIME_WAIT означава че сокета е затворен от твоята страна, демек предполагам сървъра. Ако връзката се е обслужвала от child процес, който е терминиран след затварянето на сокета, PID 0 е нещо нормално. Много странното обаче е ако тези връзки висят прекалено дълго в това състояние, би трябвало относително скоро да си заминат. При първия пакет изпратен отсреща или след някакъв относително кратък таймаут. Ако не се лъжа, включително и за този таймаут си има procfs врътка.

[Breakfist]

TIME_WAIT го показва при потребителя (В момента комуникирам с човек, който има такъв проблем и чрез TeamViewer гледам при него какво е положението). На сървъра обаче същите връзка са ESTABLISHED. И просто ме удря в земята, нямам представа какво да направя повече.. А не откривам начин и да ги прекратя принудително. До колкото четох в Google, TIME_WAIT е вече затворена връзка (което каза и ти всъщност), която продължава да стои активна още Х време, от гледна точка на сигурността, за да не се дублират пакети на един порт. Не разбирам обаче как затворена връзка ми я показва established от сървърната страна..

[gat3way]

Ми според мен клиентския софтуер е написан нагло и не затваря сокетите си културно. Може би е добре да свалиш TCP keepalive таймаута на сървъра да не е няколко часа? Би трябвало като изтече отреденото му време, сървъра да прати keepalive пакет, клиента да му върне RST и нещата да се приключат. Ще си докараш повече трафик на сървъра, но това не мисля че ще е особено голяма болка.

[daniel_vulchev]

lsof -n -i@127.0.0.1
при bsd може tcpdrop но при линукса май не поддържаше TCPCTL_DROP
може да пробваш
netstat --program --numeric-hosts --numeric-ports --extend и после
 find -inum inode number 
и после
find . -inum inode number  -exec rm -i {} \;

ако това ти върши работа  тая бира свършване няма 

[4096bits]

Според мен това трябва да се реши от клиентската страна. След като проблема е там.

[daniel_vulchev]

Аз имам подобен проблем сега http://prntscr.com/6o2rjd отварям си пощата от майлбг после излизам и искам да влезна с друга поща но рутера не е прекъснал връзката и на другата поща получавам отговор , че в момента сървъра не работи опитайте след 15 мин

[BRADATA]

Аз имам подобен проблем сега http://prntscr.com/6o2rjd отварям си пощата от майлбг после излизам и искам да влезна с друга поща но рутера не е прекъснал връзката и на другата поща получавам отговор , че в момента сървъра не работи опитайте след 15 мин

Това дето си го шернал не ми се отваря, ама ще се опитам да предположа.... Искаш да влезеш с друго име и парола или искаш да отвориш друг уеб интерфейс на друг пощенски сървър? БТВ по отношение на уеб интерфейсите рутера ти няма мешавина. Ако отвориш два браузъра (различни) ще можеш едновременно да ползваш мейлбг. С различни юзъри разбира се.