Broadcast - UDP und TCP in einem Projekt?

[.chicken]

Also ich habe ne Frage. Ich habe hier im Forum gelesen, dass Broadcasts im Netzwerk, mit welchen ich eine Liste der verfügbaren Server im Netzwerk kriegen möchte, nur mit UDP gehen. Mein restliches Projekt lasse ich aber eigentlich über TCP laufen. Kann bzw. ist es "gut" nun eine UDP Komponente, nur für den Broadcast zu verwenden? Zusätzlich zur TCP Komponente?

Worin liegt eigentlich der Unterschied?

Danke schonmal :)

[Torpedo]

Das kannst du schon machen, also beide benutzen.
Bei TCP wird eine Verbindung zur Gegenstelle aufgebaut, die auch sicherstellt, dass das ankommt, was man abgeschickt hat.
Bei UDP wird einfach drauf losgeschickt, was den Vorteil hat, dass es schneller ist, wenn man viele Daten hintereinander schicken will (z.B. bei Egoshootern) und man kann eben Broadcasts senden. Nachteil: Man kann nicht sichergehen, dass die Daten fehlerfrei, oder ob sie überhaupt, angekommen sind.

[Apollonius]

Für einen groben Überblick über die Unterschiede ist Wikipedia ganz nützlich: TCP UDP
TCP ist verbindungsbasiert, d.h. vor der Kommunikation muss eine Verbindung eingerichtet werden, weshalb auch ein Broadcast nicht möglich ist. Dafür ist jedoch sichergestellt, dass alle geschickten Pakete auch wirklich ankommen. Dies ist in UDP anders. UDP benötigt keinen Verbindungsaufbau, dafür können aber Daten verloren gehen.
Ich verwende in einem Spiel von mir auch TCP und UDP. TCP für die eigentliche Kommunikation und UDP für einen Broadcast, mit dem ich die im Netzwerk verfügbaren Server abfrage.

[.chicken]

Ok, also ist das keineswegs schlimm oder schlechter Stil oder sowas beides zu verwenden?

[sirius]

Bei UDP reicht einfach ein Socket. Mit dem kannst du überall hin senden und von überall empfangen.
Bei TCP existiert eine Verbindung zwischen zwei Hosts (die auch gleich sein können) und es können nur zwischen den beiden Daten ausgetauscht werden. Dazu benötigt man erstmal auf einer Seite einen Listener-Socket (die Seite nennt man Server). Dieser Socket macht nix weiter als auf Verbindungsanfragen zu warten und bei einer eingehenden Verbindung einen weiteren Socket zu initialisieren über den du dann mit dem jeweiligen Partner (und nur dem) kommunizieren kannst. Der Client ist es etwas kürzer. Du richtest den Socket ein und verbindest dich einfach zu einem Server (bzw. stellst die Anfrage an dessen Listener-Socket).
(die mehreren serverseitigen Sockets werden meist in einer Komponente verwaltet)


Ich hätte da noch ein Komponente, die das alles erledigt.

[.chicken]

Ok, danke, auch für die Komponente. Ich versuch aber das selbst zu lösen ohne die Komponente ;-) Dankeschön :)

[.chicken]

So, also eigentlich dachte ich ich finde hier genug dazu im Forum, aber irgendwie bin ich doch nicht so fündig geworden. Wie realisiere ich dass denn nun?

Hat vll wer ne Anleitung oder n Codebeispiel oder sowas? Dann könnte ich das nachvollziehen, habe hier im Forum irgendwie nicht wirklich was gefunden.

Muss ich einfach eine Nachricht senden und bei Empfang eine Nachricht mit Name, IP etc des Servers zurückschicken? Und wenn, muss ich dann nen UDP Client und Server machen oder wie? Habe bisher nur mit TCP gearbeitet :oops:

[sirius]

Eigentlich gibt es bei UDP keine Unterscheidung zwischen Server und Client. Bei Indy wird es dennoch gemacht. Vielleicht, weill man beim Client davon ausgeht, dass nix empfangen wird und damit Code gespart werden kann.

Die UDPsocket-Komponente von Borland ist etwas schwach (da kann man auch gleich die WinAPI nehmen), deswegen habe ich mal bei Indy geschaut.
Du benötigst:
TidUDPServer mit folgenden Einstellungen (ich lege den Port mal auf 6000)
-DefaultPort: 6000
-BroadCastEnabled: True
-und wenn du etwas machen willst (empfangen oder senden): natürlich active auf true
und dann noch sowas hier:

Delphi-Quellcode:

procedure TForm1.IdUDPServerUDPRead(Sender: TObject; AData: TStream;
  ABinding: TIdSocketHandle);
var s:string;
begin
  setlength(s,aData.size);
  aData.Read(s[1],length(s));
  showmessage(s);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  idUDPServer.Send('255.255.255.255',6000,'Hallo');
end;

Edit: Aber ich bin in Indy nicht wirklich bewandert, vielleicht gibts noch andere Möglichkeiten (z.B. die Methode Broadcast)

[.chicken]

Zitat:

Zitat von sirius

Eigentlich gibt es bei UDP keine Unterscheidung zwischen Server und Client. Bei Indy wird es dennoch gemacht. Vielleicht, weill man beim Client davon ausgeht, dass nix empfangen wird und damit Code gespart werden kann.

Die UDPsocket-Komponente von Borland ist etwas schwach (da kann man auch gleich die WinAPI nehmen), deswegen habe ich mal bei Indy geschaut.
Du benötigst:
TidUDPServer mit folgenden Einstellungen (ich lege den Port mal auf 6000)
-DefaultPort: 6000
-BroadCastEnabled: True
-und wenn du etwas machen willst (empfangen oder senden): natürlich active auf true
und dann noch sowas hier:

Delphi-Quellcode:

procedure TForm1.IdUDPServerUDPRead(Sender: TObject; AData: TStream;
  ABinding: TIdSocketHandle);
var s:string;
begin
  setlength(s,aData.size);
  aData.Read(s[1],length(s));
  showmessage(s);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  idUDPServer.Send('255.255.255.255',6000,'Hallo');
end;

Edit: Aber ich bin in Indy nicht wirklich bewandert, vielleicht gibts noch andere Möglichkeiten (z.B. die Methode Broadcast)

Ok, mit der zweiten Prozedur, wird das dann an alle IPs gesendet? Also quasi von 0.0.0.0 bis 255.255.255.255?

Und ansonsten nehme ich noch nen UDP Client bei der ClientAnwendung und da dann noch ne Read und Send Methode?

Danke schonmal!

Edit: Achso, warum is das mit nem Stream und nich einfach nem String? Gibts keine Möglichkeit einfach simpel nen String zu versenden? Ohne Stream?

[sirius]

Das war eigentlich schon alles. Du brauchst keine weitere Komponente oder weiteren Code. Die erste Methode ist das Ereignis onUDPRead (du musst ja in jedem Programm lesen und senden können, das macht hier eine Komponente)
Die zweite Methode sendet ein Hallo (255.255.255.255 ist die BroadCast-IP und sagt dem Router nur, dass er die Pakete in alle Richtungen schicken soll - übrigens auch zurück)