Broadcast, Multicast, TCP-Connection

Beschreibung:

Broadcast_example ist ein kleines Projekt, welches während der Entwicklung eines größeren Programms mit entstanden ist.

Im Prinzip ist es ein vollständiges Netzwerkframework. Broadcast und Multicast (über UDP) kann vom Server verwendet werden um den Clients die IP und den Port der TCP Verbindung mit zu teilen. Die Clients können sich dann zum Server verbinden ohne Konfiguriert zu werden.

Außerdem ist eine Serialisierung / Deserialisierung für Structs enthalten und sogar der Code für eine Komprimierung der Daten, welcher zur Zeit aber nicht genutzt wird. Kann jeder selber leicht einbauen.
Später soll der Netzwerkstream automatisch in die Structs verwandelt werden und ein Event für jedes Packet geworfen werden. Das habe ich für Klassen bereits implementiert aber nicht mit in diesem Projekt.
Es wird aber bereits in allen Assemblies nach Implementationen von IPacket gesucht womit jedes Paket dynamisch eine eindeutige ID bekommt. Später muss dem Netzwerkstream dann noch die Information über Paketlänge und Paket id hinzugefügt werden damit der NetworkMessageHandler die Pakete als Structs generieren kann.
Auch mit den ID's muss noch sichergestellt werden das die Pakete immer die selben ID's bekommen. Vielleicht muss die ID doch noch eine Property oder ein Attribut der Paket Structs werden.

Funktioniert nur im LAN! Im Internet werden keine Broadcasts / Multicasts geroutet.
Nicht alle Router unterstützen Broadcast und Multicast. Mit dem Tool kann man das schnell bei seinem eigenen Router testen.

Es kann:*Client: Broadcasts / Multicasts in einer MulticastGroup und einem Port empfangen *Client: Automatisch zu einem Server verbinden, welcher den BC / MC gesendet hat *Server: Broadcast an eine IP Senden *Server: Multicast in eine MulticastGroup senden *Server: TC Verbindungen annehmen. (Bisher nur Port 1337)

TODO:* Serverport für TCP Verbindungen änderbar

• PacketHandler fertig stellen: Networkstream in Structs parsen und Events werfen
• Auslagerung in eine DLL

Der Quellcode ist teilweise Dokumentiert. Fragen beantworte ich gerne.
Auch Kritik und Verbesserungsvorschläge sind willkommen.

Schlagwörter: Broadcast, Multicast, TCP, Server, Client, Netzwerk, Network

hallo Tarion,

ich habe deinen code mal rudimentär betrachtet und mir sind folgene punkte aufgefallen:

1. du musst nicht manuell prüfen ob das objekt disposed ist und dann eine ObjectDisposedException schmeissen. das macht das framework auch so für dich.
2. bei UDP kenne ich es so, das generell alles 4-6 mal im stil von fire&forget gesendet wird. hintergrund ist der, das packete im allgemeinen öfters verloren gehen können, als es den meisten bewusst ist. eine option hierfür wäre zumindest von vorteil, da bei mehrmaligen aufrufen von außen je jedesmal neue sockets erstellt werden.
3. verwende das using {...} um sicherzustellen, das objekte auch beim auftreten von exceptions disposed werden. z.b. sockets.
4. verwende lieber den threadpool anstatt in einer liste manuell threads zu erstellen.
5. der networklistener hat busy-waiting implementiert. das ist nciht gut. das solltest du überdenken.

ansonsten eine nette idee und sicher mal brauchbar. werd ich mir mal merken 😉

1. du musst nicht manuell prüfen ob das objekt disposed ist und dann eine ObjectDisposedException schmeissen. das macht das framework auch so für dich.

Im folgenden Beispiel gibt es keine Exception. Oder was genau meinst du übernimmt das Framework.

Disp myDisposable = new Disp();
myDisposable.Dispose();
myDisposable.Dispose();
myDisposable.Foo();

// Mit dieser Klasse:
public class Disp : IDisposable
    {
        int x;
        public void Foo()
        {
            x++;
        }

        #region IDisposable Members

        public void Dispose()
        {
            Console.WriteLine("Dispose Test");
        }

        #endregion
    }

2. bei UDP kenne ich es so, das generell alles 4-6 mal im stil von fire&forget gesendet wird. hintergrund ist der, das packete im allgemeinen öfters verloren gehen können, als es den meisten bewusst ist. eine option hierfür wäre zumindest von vorteil, da bei mehrmaligen aufrufen von außen je jedesmal neue sockets erstellt werden.

Jedes mal x Packets senden ist schnell implementiert. Werde ich einabuen.

3. verwende das using {...} um sicherzustellen, das objekte auch beim auftreten von exceptions disposed werden. z.b. sockets.

Stimmt.

4. verwende lieber den threadpool anstatt in einer liste manuell threads zu erstellen.

Ich habe x Threads welche die ganze Zeit arbeiten.
Ich würde permanent einen Thread pro Verbindung aus dem Threadpool nutzen und wenn der Pool leer ist kann ein Client nicht behandelt werden. Das kann mir mit meinen 10 Threads die auf einer Queue arbeiten nicht passieren. Eventuell reicht 1 Thread. Aber mehrere Tthreads können bei Komplexen Geschichten die Antwortzeiten erhöhen. Auch kann ein Thread mal hängen bleiben und die anderen arbeiten auf allen anderen Clients weiter.
Für Berechnungen und zeitlich begrenztere Aufgaben stimme ich dir zu. Hier sehe ich den Vorteil vom Threadpool so noch nicht.

5. der networklistener hat busy-waiting implementiert. das ist nciht gut. das solltest du überdenken.

Was meinst du mit Busy waiting?

`private void AcceptThread()
        {
            while (accepting)
            {
                if (listener.Pending())
                {
                    TcpClient client = listener.AcceptTcpClient();
                    clients.Enqueue(client);
                    ThreadSaveEvent.InvokeEventSave(ClientConntected, this);
                }
                Thread.Sleep(100);
            }
            listener.Stop();
        }

Geht das besser? Oder meinst du was anderes.

Was meinst du mit Busy waiting?

im sinne von polling. polling ist imer schlecht und auch in diesem fall nciht notwendig.

Im folgenden Beispiel gibt es keine Exception. Oder was genau meinst du übernimmt das Framework.

siehe:
Dispose implementieren und verwenden

Ich würde permanent einen Thread pro Verbindung aus dem Threadpool nutzen und wenn der Pool leer ist kann ein Client nicht behandelt werden.

deswegen musst du das ganze eventdriven machen. ein thread ist etwas was in erster linie mal ressourcen frisst. du kannst auch nicht unendlich viele davon erstellen. des weiteren kann deine cpu uach nur immer eine bestimmte anzahl an threads gleichzeitig ausführen. das switschen von einem thread zum anderen (also zeitscheibe weitergeben) kostet ressourcen. desto mehr threads du hast, desto öfters muss geswitched werden (kleinere zeitscheiben für alle), desto größer ist der overhead und das im quadrat.

Hier sehe ich den Vorteil vom Threadpool so noch nicht.

ich sehe das genau anders herum. ich sehe fast immer keine vorteile einer liste von threads im vergleich zum threadpool.

Was meinst du mit Busy waiting?

im sinne von polling. polling ist imer schlecht und auch in diesem fall nciht notwendig.

Aber wenn ich die Abfrage weg lasse, hängt er im Receive. Dann kann ich den Thread nicht beenden. Zumindest hab ich es nie richtig hin bekommen. Ne Lösung dafür würde mich interessieren.

Und wgen den Threads hab ich ja nur eine limitierte Anzahl, die man bei bedarf auch auf 1 stellen kann.

Gruß, Tarion

Aber wenn ich die Abfrage weg lasse, hängt er im Receive. Dann kann ich den Thread nicht beenden. Zumindest hab ich es nie richtig hin bekommen. Ne Lösung dafür würde mich interessieren.

event-driven. das genze geht mit callbacks und events ganz gut. eben asynchron.

Bitte keinen fachlichen Fragen in Snippets-Threads. Dafür gibt es die Foren der Kategorie Entwicklung.