On Fri, 02 Nov 2018 09:40:09 +0100, Roman Tyczka wrote:
> Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
> Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
> niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
> chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
> windowsowych socketów. Od czego zacząć, jak ugryźć?
Na tak zadane pytanie naprawdę nie wiem co odpowiedzieć, bo nie rozumiem
co kolega kombinuje. Odpowiem jak umiem.
Połączenie P2P to nic innego jak połączenie między jednym hostem a
drugim, bez udziału dedykowanego serwera. W praktyce jeśli chcemy móc
nawiązać połączenie w sposób niezależny od tego która ze stron jest
inicjatorem, to obie strony muszą posiadać socket otwarty w trybie LISTEN.
Czyli de facto oba hosty są "serwerami". Przykładem takiej implementacji
jest popularne NTP. NTP działa co prawda z UDP, ale przy TCP zasada jest
podobna. W naturze TCP leży pojęcie "serwera" i "klienta", więc dodatkowa
trudność przy TCP polega na ustaleniu kto będzie robił za serwer a kto za
klienta. Tutaj rozwiązania do głowy przychodzą mi (tak na zaraz) trzy:
1. jeśli adresy IP obu hostów są z góry znane, to ew. przyjąć że ten
niższy jest zawsze serwerem, więc niech wyższy się łączy.
2. oba hosty nasłuchują na porcie x, jednocześnie starając się nawiązać
równoległe połączenie z rozmówcą z innego socketu. Jak tylko komuś uda
się nawiązać połączenie, likwiduje swój socket nasłuchujący (a druga
strona zaprzestaje prób połączenia w drugą stronę).
3. oba hosty przechodzą losowo w tryb serwer/klient. Np. pierwsze 5s host
czeka na połączenie z zewnątrz. Jeśli się nie uda, to przechodzi w tryb
klienta i sam próbuje nawiązać połączenie z drugą stroną przez kilka
sekund. Długość okresów klient/serwer wypadałoby losować, coby uniknąć
nieszczęśliwej synchronizacji w której oba hosty zawsze są w tym samym
trybie.
Każda z powyższych metod ma swoje wady i zalety. Wybór zależy głównie od
założeń projektowych.
Od strony programowej nie ma tu nic szczególnego. Logika będzie różna
zależna od wersji 1/2/3, ale "klient" zawsze będzie musiał wykonać kroki
socket() + connect()
...a "serwer" zawsze będzie musiał wykonać kroki socket() + bind() +
listen() + accept()
Jeśli celem jest stworzenie jakiegoś własnego protokołu do wymiany
danych, to wybór UDP wydaje się (hobbystycznie patrząc) ciekawszy.
Pozwoliłby w dużo bardziej elegancki sposób rozwiązać etap nawiązywania
sesji, i pozwoliłby na dużo większą dowolność w implementacji metod
transferu danych.
Całkiem możliwe również że kompletnie nie zrozumiałem pytania, w takim
razie zalecam uściślenie.
Mateusz
|