Lista pecet@man.lodz.pl
[Lista archiwów] [Inne Listy]

Re: [PECET] opoznienia na switchu

To: pecet@man.lodz.pl
Subject: Re: [PECET] opoznienia na switchu
From: Roman Tyczka <noemail@because.no>
Date: Fri, 2 Nov 2018 12:41:02 +0100
On 02 Nov 2018 11:03:49 GMT, Mateusz Viste wrote:

> On Fri, 02 Nov 2018 10:59:01 +0100, Roman Tyczka wrote:
>> Rzeczywiście za mało precyzyjnie napisałem. Używając określenia P2P
>> miałem na myśli nie tylko bezpośrednie połączenie host-host, co jest
>> oczywiste,
>> ale dalsze problemy jakie za tym idą, czyli nawiązanie połączenia
>> omijającego NAT. Czytałem gdzieś kiedyś o tym, że sprawa opiera się o
>> niskopoziomowe manipulowanie nagłówkami TCP/IP w czasie zestawiania
>> połączenia, potem to już z górki (w sensie, że sama komunikacja jest
>> innym etapiem, a problemem jest nawiązanie połączenia). Takie rzeczy
>> robi skype, torrenty czy kiedyś emule.
> 
> Nie ma cudów - aby Grześ z Krzysiem mogli pogadać po TCP, to jeden z nich 
> co najmniej musi być poza NATem. Jeśli obaj są za NATem, to pomóc może 
> jedynie oparcie się na osobie trzeciej.
> 
> Z UDP można próbować kombinować, ale to niezwykle upierdliwa sprawa:
> 
> Krzyś wysyła datagramy UDP do Grzesia, z portu src 5000 do portu dst 6000.
> 
> Krzyś -> RouterK -> INTERNET -> RouterG -> Grześ
> 
> Po drodze RouterK zmienia port źródłowy datagramów na, dajmy na to, 20000.
> 
> W takiej sytuacji Grześ może tylko próbować wysyłać tysiące pakietów do 
> Krzysia, z losowymi portami src licząc, że RouterG w którymś momencie 
> podmieni port src na akurat ten wybrany przez RouterK. Słowem całkowita 
> loteria. Dla zwiększenia szans powodzenia, Krzyś może rozpocząć 
> kilkanaście sesji UDP z różnymi portami src, coby Krzysiowi było łatwiej 
> trafić.
> 
> Aby zrozumieć tandetność tej sytuacji, należy zrozumieć co tak naprawdę 
> robią RouterK i RouterG.
> 
> Kiedy router dostaje jakiś pakiet z wewnątrz:
>  1. zmienia port src
>  2. zmienia IP src
>  3. oblicza nowy checksum TCP (lub UDP)
>  4. zapisuje sobie w pamięci (w tzw. tablicy sesji) informację co 
> przetłumaczył, od kogo i na co.
> 
> Kiedy router dostaje jakiś pakiet z zewnątrz:
>  1. sprawdza w tablicy sesji czy posiada wpis odpowiadający tuplowi IPsrc
> +IPdst+portSrc+portDst.
>  2. Jeśli któryś z wpisów tablicy sesji się zgadza, to podmienia adres 
> DST i port DST zgodnie z wpisem.
> 
> Wynika z tego, że aby ustalić połączenie z kimś za NATem, trzeba 
> wystarczająco szczęścia by wstrzelić się w parametry wpisu tablicy sesji. 
> A parametry te zna tylko sam router. Porty to wartości szesnastobitowe 
> (przy czym zakres 0-1024 można pominąć), więc kombinacji jest tylko nieco 
> ponad 4 miliony. Ale to dalej loteria.
> 
> Odpowiadając na pierwotne pytanie: nie ma takiej magii, która pozwoliłaby 
> ustawić na sockecie flagę "P2P" aby dostać się do dowolnego hosta za 
> NATem.

Ok, w takim razie JAK aplikacja typu torrent łączy się z setkami innych
punktów w sieci P2P, z tymi za NATem także (mimo, że sama też jest za
NATem)? 
Czytałem kiedyś opis tej technologii, padały tam nazwy pewnych technik i
odbywało się to niskopoziomowo, niestety wtedy mnie to mniej interesowało i
nie pamiętam, a teraz chętnie bym się tym pobawił. I to działa na IPv4, na
100%.

-- 
pozdrawiam
Roman Tyczka

<Pop. w Wątku] Aktualny Wątek [Nast. w Wątku>