On 6/25/25 21:31, Mirek wrote:
> W dniu 25.06.2025 o 09:52, J.F pisze:
>
>> Pewnie można zaryzykować. albo sprawdzic kilka kolejnych, na wypadek,
>> gdyby ktos się wciął.
>>
>> Ale trafi na "dobry" router, co wylosuje, i d* :-)
>>
>
> No to się inicjuje więcej połączeń z jednej strony i wielokrotnie trafić
> z drugiej strony. Na tej publikacji co podał kolega Cezar jest przykład:
> 256 zainicjowane połączenia i 1024 próby daje paradoksalnie 98% szans na
> powodzenie.
> Ciekawa sprawa jest z "simultaneous transmission trick" - nie wiem o co
> chodzi, ale chyba nie o adresy multicastowe, bo to raczej też nie realne.
> Teoretycznie gdyby wysłać pakiet do serwera uzgadniającego p2p i
> następnie zmusić jakoś system, żeby użył tego samego socketu - czyli de
> facto zmusić do przydzielenia takiego samego portu wyjściowego i
> następnie wysłać do docelowego peera to bylibyśmy w domu.
> Ale nie wiem czy tędy droga - może kolega Cezar nam wyjaśni skoro
> twierdzi że w tym siedzi.
>

to jest typowe "hole punching"

Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w
małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują
ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po UDP.

Problem jest oczywiście z tym że nie wiadomo jaki src port da firewall
pakietowi wychodzącemu, dlatego zestawia się N połączeń żeby zwiększyć
szanse na trafienie.

Oczywiście do tego potrzebny jest jakiś koordynator - NP połączenie po
TCP do jakiegoś serwera, które wymienia informację pomiędzy peerami. To
połączenie nie jest używane później do przekazywania właściwych danych.



Tutaj na prędce napisałem klienta
https://smalldev.tools/share-bin/v1ZAJVmQ

i serwer do wymiany IP

https://smalldev.tools/share-bin/hTCznAFu


U mnie nawiązuje otwiera firewalle po kilku sekundach ale są raczej
głupawe, bo przydzielają porty źródłowe sekwencyjnie



c.