Ile średnio bajtów potrzebuje by utrzymać jałową sesje TCP/IP przez minimum 100sec?
JEŚLI NIE ZNASZ ODPOWIEDZI, PROSZĘ NIE ODPOWIADAJ!!!
Ile średnio bajtów potrzebuje by utrzymać jałową sesje TCP/IP przez minimum 100sec?
JEŚLI NIE ZNASZ ODPOWIEDZI, PROSZĘ NIE ODPOWIADAJ!!!
Ostatnio edytowane przez Nikow : 07-19-2008 - 16:46
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
ze co?
sesje utrzymasz, poki client lub server nie dostanie timeouta.
choc jesli zamierzasz 'zamrozic' komunikacje, to tcp nie byloby najlepszym rozwiazaniem.
Twój system sam zatroszczy się o stan sesji TCP/IP. Jeśli druga strona nagle "zniknie" (brutalne odłączenie interfejsu sieciowego, zanik napięcia, kernel panic) to mechanizm TCP keep-alive spowoduje zerwanie połączenia.
Keep-alive jest defaultowo wylaczony. Po prostu recv() musi wyleciec z < 0.
Wiem o co pytam, więc proszę jeśli nie znacie odpowiedzi to nie odpowiadajcie. Pytałem ile bajtów "kosztuje" utrzymanie jałowej sesji TCP/IP! Nie o keep-alive, timeout'y czy co zrobi system, ponieważ to wiem! Znam protokół TCP/IP, napisałem własną implementacje... Proszę o odpowiedź na moje pytanie, nie na wasze chwalenie się wiedzą, którą też posiadam. O timestapie w TCP też wiem, o ecku, flagach i innych pierdołach TCP... Jedna prawidłowa informacja.
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
generalnie nie jestem programista, ani nie moge podeprzec sie zadnymi dokumentami, jednak na podstawie obserwacji mam powody sadzic iz samo utrzymanie sesji nic nie kosztuje
nieraz zdarzalo mi sie bedac zalogowanym przez ssh mieszac z kablami/routingiem, jesli w tym czasie ssh nie wysylal zadnych pakietow (czyt: nic nie wpisywalem) i nie wykryl braku polaczenia, po przywroceniu lacznosci ssh bylo dalej aktywne nawet jesli trwalo to kilka-kilkanascie minut, moze i dluzej
to juz w zaleznosci od konkretnego programu i jego ustawien, po uplynieciu okreslonego czasu nieaktywnosci sesje sa rozlaczane (np ftp), albo mechanizm wykrywania martwych polaczen, czy jak je tam zwac, wywala polaczenie (np irc, on chyba pinga wysyla)
(jesli o to pytales =])
Ostatnio edytowane przez rist : 07-18-2008 - 21:45
Nikow, nie czaruj. Twoja marna "implementacja" na pewno nie działa skoro zadajesz tak podstawowe pytania. Wracaj do piaskownicy. Odpowiedź na Twoje pytanie jest w moim pierwszym poście.
rip, tcp keep-alive w nowoczesnych systemach jest właczony, dzięki czemu nie ma problemu "wiszących" połączeń.
Ostatnio edytowane przez elceef : 07-18-2008 - 22:41
zdefiniuj nowoczesne systemy :P
ale mniejsza z tym, generalnie to juz program a nie sama sesja, prawda?
Uwierz mi, wiem na czym polega keep-alive, ale to ma się nijak do zużycia łącza przez jałową sesje TCP/IP! TCP keep-alive chroni przed padniętymi sesjami, jest to wysyłanie co pewien czas pakietu bez danych z flagą ACK, który sprawdza czy połączenie jest dalej aktywne, jednak timer jest ustalany dynamicznie, więc sam wracaj do piaskownicy! Chodzi mi o to, ile średnio bajtów muszę poświęcić na utrzymanie jałowej sesji tcp/ip w danym oknie czasowym, które ustaliłem minimalnie na 100sec.
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
Timer dla TCP keep-alive nie jest ustalany dynamicznie. Każdy system ma statycznie ustawione wartości timerów, wcale nie musi ich dopasowywać. Każda strona sprawdza połączenie we własnym zakresie.
W przypadku wyłączonego mechanizmu TCP keep-alive (po obu stronach połączenia!) odpowiedź na Twoje pytanie brzmi: 0 (słownie zero) bajtów. Przy włączonej zależy od konkretnych implementacji stosu TCP/IP. A wystarczyło przeczytać to co napisałem wcześniej i trochę pomyśleć.