Wie viele Sockets bei P2P Programm?

[Red six]

Tag Leute,

nur eine kurze Konzeptfrage für ein P2P Programm, dass eine mehr oder weniger große Anzahl von Usern supporten soll.

Was denkt ihr ist intelligenter:
Pro Client jeweils ein Server/Client Socket oder pro Verbindung? Da sehr viele Daten gleichzeitig gesendet werden sollen, tendiere ich zu zweiterem. Außerdem wäre es wegen dem gesamten Handling wesentlich angenehmer. Nachteilig ist natürlich, das relativ viele Ports belegt werden würden, aber es gibt ja zum Glück genug

Hat jemand damit Erfahrungen?

Jede Tipp ist willkommen,

danke,

rs

[Klaus01]

ein Beispiel.

client1 Port: 1234 -> Server1 Port: 8000
client2 Port: 4895 -> Server1 Port: 8000

so ganz verstehe ich Dein Problem nicht.
Willst Du mehrere Clients pro Rechner laufen haben?
Der Server horcht in der Regel auf einem bestimmten Port,
das ist auch der Port auf den sich die Clients verbinden müssen.
Ein Server kann in der Regel viele Clients verwalten.
Es ist meiner Meinung nach nicht notwendig pro Client einen
extra Server laufen zu lassen.

Willst Du tcp oder udp nutzen?

Grüße
Klaus

[Red six]

Hallo Klaus,

das ganze soll ohne Server ablaufen, Peer-2-Peer, wie gesagt. Als Beispiel könnte man einen BitTorrent Client nehmen, jeder ist mit jedem Verbunden, ein zentraler Server ist nur für den Verbindungsaufbau zuständig (IP Adressen austauschen, ggf. TCP hole punching).

Das ganze soll per TCP laufen, es ist wichtig dass alle Daten bei jedem komplett ankommen.

[himitsu]

Wie willst du ohne einen Server die Clients miteinander verbinden?
also woher soll ein Client wissen, wo der/die andere(n) Client(s) sind

[NickelM]

Muss ich zustimmen. Ein Server ist in deinem Fall der Computer, auf dem die Daten existieren, die du senden willst.
Du musst nun mit dem Client zu diesem "Server" verbinden. Wenn du dass mit Indy machen willst brauchst du auf dem Rechner, wo die die daten senden willst eine IdTcpServer und auf dem anderen halt nen Client. Wi du jetzt Daten hin und her schickst, keine Ahnung. Hab noch nie damit gearbeitet.
Du kannst ja dan so eine Art von Msg senden, die besagt, sende die dAten, wenn gesendet, warten bis alle anderen es auch haben. Wenn der letzte es hat verbindung beenden oder so.
Hoffe konnte dir ein wenig näherbringen, wie du in etwa vorgehen kannst.

[Red six]

Ok also nochmal von vorn:

Ich verwende mal die Bezeichnung Peer, vielleicht ist es dann besser verständlich.

Jeder Peer erzeugt Daten. Diese Daten sollen dann zu jedem anderen Peer gesendet werden. Das heißt jeder Peer ist mit allen anderen Peers verbunden. Meine Frage ist: Jeweils ein Server SOCKET und ein Client SOCKET pro Peer, oder mehrere SOCKETS pro Peer.

Bsp:
ENTWEDER:

Ein Peer hat einen Server Socket und einen Client Socket.
4 Peers: A, B, C, D.

Wenn sich Daten bei Peer C ändern, schickt er diese an den Server Socket von Peer A und B.
Server@Peer A empfängt die Daten, und leitet sie an Server@Peer D weiter, während Client@Peer C noch an Server@Peer B sendet.
Nun haben alle die aktuellen Daten. Wenn jetzt aber alle gleichzeitig neue Daten erzeugen, könnte das ganze etwas langsam werden, vorallem wenn es sich um mehr Peers handelt als in diesem Beispiel.


ODER:

Jeder Peer hat für jede Verbindung eine Klasse

Delphi-Quellcode:

TConnection = class
private
   FClient: TClientSocket;
   FServer: TServerSocket;
end;

Immer wenn sich etwas an seinen Daten ändert, schickt er diese Änderung an alle TConnections.


Der physikalische SERVER den ihr meint, existiert nur als Vermittler. Er sagt jedem der Peers, welche IP die anderen Peers haben. Daraufhin stellt jeder Peer eine Verbindung zum anderen her.


*edit*

Ich glaube mir ist gerade die Lösung eingefallen.

Jeder Peer hat einen Server Socket und für jeden anderen Peer einen eigenen Client Socket. Müsste optimal sein, oder?

[NickelM]

In deinem Fall würde es 2 Richtige möglichkeiten geben, jenachdem wie du es brauchst, weil:

Beispiel:
Peer A,B,C,D
Peer A hat einen Server, die anderen nur Clients

Peer B,C oder D kann dan nur mit A verbinden, weil bei den anderen Peers keiner ist, der die Daten empfängt, weil das nur Server können, also kann Peer B nicht mit Peer C oder D verbinden, da kein Server vorhanden ist.
Also kann, wenn Peer D Daten hat, nur an Peer A senden. Diese kann dan nicht an Peer D und C senden, weil sie keinen Server haben.

1. Möglichkeit
Wenn bei jedem Peer ein Server ist und mehrer Clients, dann kann Peer A mit Peer B und C oder Peer C mit Peer D,B und A und so weiter verbinden.
Du musst also einen Array von Clients machen und einen Server je Peer. Beispiel:
Wenn sich die Daten bei Peer A zum Beispiel ändern, kann Peer A mit Peer B, C und D verbinden und sie senden.
Dass gleiche mit Peer B, der sich dan mit Peer A,C und D verbinden kann und senden kann.
Das würde dan in etwa so ausehen:

Delphi-Quellcode:

TPeer = class 
private 
   FClient: array of TClientSocket; 
   FServer: TServerSocket; 
end;

2. Möglichkeit:
Jeder Peer hat nur einen Server und Client.
Peer A hat Daten für die anderen Peers. Peer A senden sie an Peer B, der sendet sie dann an Peer C und der wiederum dan an Peer D. So haben dan auch alle die Daten.
Das würde kann wie du schon gesagt hast aussehen

Meiner Meinung nach ist die 1. Möglichkeit am günstigsten. Nachteil ist halt, das ein Peer ziemlich viel zu tun hat, bei der 2. Möglichkeit kostet es eher Zeit.

[Red six]

Ok alles klar, danke. Dann werd ich Version 1 nehmen.