Warum ist System.Net.Sockets.Socket abgefuckt?



  • Erklär mal bitte Optimizer... 🙂



  • - Weil verschiedene Sockettypen nicht über verschiedene Klassen realisiert sind. Du musst im Konstruktor den Typ deines Sockets angeben (z.B. StreamSocket). Du musst du dich für eins von 809824364 Adressfamilies, Protokollen und Sockettypen entscheiden. Der Gag ist jetzt, dass natürlich nicht für jeden Sockettyp jedes Protokoll verfügbar ist. Du darfst jetzt also Doku lesen und feststellen, was überhaupt gültige Kombinationen sind.
    Wenn es einfach nur ne Klasse StreamSocket, von Socket abgeleitet geben würde und dafür ein enum StreamSocketProtocolls, wäre das wesentlich weniger hässlich.

    - Die Schnittstelle ist unglaublich hässlich fett. Send(), BeginSend(), SendTo(), ... und natürlich ist nicht alles für jeden Sockettyp /Protokoll / AddressFamily erlaubt. SendTo() darf man nur bei UDP-Verbindungen verwenden. Die anderen darf man dort nicht verwenden. Warum es keine eigene Klasse UdpSocket gibt, die nur SendTo() hat, ist mir ein absolutes Rätsel. Bei jedem Aufruf von irgendwas müssen tausend Sachen geprüft werden und dir kommt vielleicht ne Exception entgegen, obwohl man das mit einer einfachen Klassenhierarche zur Kompilierzeit schon alles klar machen könnte.

    - Das tolle StreamSocket ist gar kein Stream. Es langweilt harcore, wenn du die ganze Zeit mit Streams arbeitest und dann ist das dumme Socket kein Stream.
    ➡ Du darfst deine ganzen Daten in einen MemoryStream schreiben, von dem das byte[] getten und das kannst du dann senden. 🙄

    - Es gibt keine Unterscheidung zwischen ServerSocket und ClientSocket. Auch das trägt zur fetten Schnittstelle bei. Obwohl ich ein Socket nur benutzen will, um Verbindungen zu akzeptieren, hat das alle möglichen Send-, Receive- und sonstwas- Methoden.

    ➡ abgefucktes Design



  • Vielleicht den ganzen Kack selbst mal ordentlich wegkapseln? Also selbst eine Hierarchie der verschiedenen Sockets bauen, die dann nur die entsprechenden Dinge können.



  • Bei uns in der Firma haben wir angefangen einen Wrapper für Teile von Leadtools (hierbei handelt es sich um ein Graphic Development Kit) zu schreiben, aber es fuckt schon ab, wenn man sich jede API, Library, Framework etc. Erst wrappen muß um vernünftig damit zu arbeiten. Nämlich grade von einem Framework erwartet man ja das es schon einiger Maßen "mundgerecht" ist.



  • Helium schrieb:

    Vielleicht den ganzen Kack selbst mal ordentlich wegkapseln? Also selbst eine Hierarchie der verschiedenen Sockets bauen, die dann nur die entsprechenden Dinge können.

    Ne, das ist mir zu aufwändig und ich sehe nicht, wieso das meine Aufgabe sein sollte und nicht die von Microsoft. Für mein Spiel habe ich eh sehr spezielle Anforderungen und schreibe mir deshalb sowieso meine eigene Connection-Klasse.
    Für allgemeinere Zwecke eine eigene Hierarchie aufzubauen, dazu fehlt mir definitiv die Lust. Es ist halt nur einfach traurig, man hätte es so viel schöner machen können.



  • Gratulation zum 4.000sten Beitrag 😉





  • Das ist halt nur die Lowlevel-Sicht der Sockets, anscheinend 1:1 vom BSD-Socketinterface abgekupfert. Das kannst du denen nicht direkt zur Last legen, eher die Tatsache, dass es anscheinend keine Highlevel-Sicht gibt.



  • Ich finde, dass wenn ich auf einen blocking Receive() warte und die Verbindung wird unterbrochen, dann sollte eine Exception fliegen und nicht einfach 0 Bytes empfangen und Connected immer noch auf true sein. 👎
    Der Gag ist doch, dass Receive tatsächlich dann abbricht, also nicht mehr blockt und trotzdem ist Connected noch auf true.

    Vielleicht hätte ich das dazu schreiben sollen, das geht aus meinem Link nicht wirklich hervor. Aber denk mal obiges durch. Findest du das in Ordnung, dass man erst was senden muss, dass er es kapiert, dass die Verbindung nicht mehr besteht? Poll() ist in meinen Augen keine Alternative, bzw. sollte ich darauf verzichten können, wenn ich schon blocking Sockets verwende.



  • Da steht by design...



  • naja,

    MS wird an der Socket-Implementierung nichts mehr ändern. Zumal MS voll auf Indigo setzt, was wiederum COM/COM+ sowie Webservice als Zugpferde einsetzt. Es gibt jetzt schon sehr schöne Frameworks für die Kommunikation (Enterprise Services, Webservices, Remoting). Man braucht sie nur zu benutzen. Da ist eine Socketverbindung in Anwendungen echt zu primitiv und nicht zeitgemäß.
    Zusätzlich hat man dann noch alle Vorteile der Integration der Authentifizierung von Windows, automatische Verschlüsselungen, Load-Balancing und automatische Serialiserung.
    Jeder der heutzutage ncoh mit Sockets oder mit TCPClient rummacht hat entweder nen Sockenschuss oder zu viel Zeit.



  • Ich glaube die Microsoft-Mitarbeiten können einfach keine Socket-Wrapper schreiben 😉 Bei MFC haben sie auch schon so ein Mist gemacht.

    http://tangentsoft.net/wskfaq/articles/csocket.html



  • Jeder der heutzutage ncoh mit Sockets oder mit TCPClient rummacht hat entweder nen Sockenschuss oder zu viel Zeit.

    Der TcpClient geht ja gerade noch, wenn man davon absieht, dass Microsoft offenbar nicht weiß, was ein Stream ist. Man braucht schon auch ein vielseitigeres Werkzeug.
    Auf der Ebene von Java-Sockets finde ich das voll ok, ich kann nicht alles mit Remoting und Webservices machen, die sind für ein paar bestimmte Anwendungsfälle praktisch und nicht mehr.

    Mit ner anständigen Serialisierung wie in Java und nicht in .Net kann man ziemlich high-level so beliebige Objekte hin und her schicken, mit 0 Aufwand.



  • ich kenne mich nicht sehr gut mit Java aus. Ich hab da noch keine Funktionalität bei den Java-Sockets gefunden, die auch nur annähernd and die Funktionalitäten (ich kann da noch mehr aufzählen als die im letzen Beitrag erwähnten. Zum Beispiel transaktionale Kommunikation, Singelton-Objekte und Caching) von Enterprise Services, Remoting oder Webservices rankommt. Und nenne mir die Funktionalitäten die Java-Sockets haben, die es in den genannten Frameworks nicht gibt.

    [EDIT] Ich möchte hiermit kein Java-.NET-Diskussion anfangen. Es geht mir nur um die Techniken[/EDIT]



  • Ich rede ja nicht von mehr Funktionalität. Es geht doch darum, dass du manchmal _ein bisschen_ mehr lowlevel bleiben musst. Für mein Echtzeitstrategiespiel mit Multiplayer-Modus nehme ich keine Webservices oder Remoting, das leuchtet doch ein, oder?
    Deshalb: Alles für sein Anwendungsgebiet. Den TcpClient kann man schon brauchen und es ist schade, dass er so schlecht designt ist. Aber wer so ein Socket wrappen muss, kann ja schon gar nichts tolles mehr hervorbringen. 🙂

    P.S.
    Du kannst ja jetzt nicht die Java-Sockets mit Webservices vergleichen. Sowas gibt's in Java auch, wenn dann müsstest du schon die Sockets vergleichen.



  • Es geht doch darum, dass du manchmal _ein bisschen_ mehr lowlevel bleiben musst. Für mein Echtzeitstrategiespiel mit Multiplayer-Modus nehme ich keine Webservices oder Remoting, das leuchtet doch ein, oder?

    hm, dein Spiel muss ich mir echt mal anschauen 🙂

    Sofern du den TCPChannel bei Remoting verwendest hast du keinerlei Nachteile gegenüber TCPClient. Geschwindigkeit ist ja die selbe. Wenn Das Framework langsammer wäre, würde ich dir Recht geben. Deshalb scheidet WebService erst einmal aus. Enterprise Services arbeitet mit DCOM, was so von der Performance her durchaus überzeugt. Also könntest du auch Enterprise Services einsetzen.

    Du hast, wie bei Remoting, mehr Funktionalität ohne Nachteile. Geschwindigkeit ist in dieser Aufgabnestellung kein Ausschlusskriterium für die Frameworks.

    [Edit]Ich hatte mal ein Projekt,bei dem ich auf (projektspezifische) Performanceprobleme gestoßen bin. Da hatte ich testeshalber auch mal auf TCPClient/TCPServer umgestellt. Hat 0 Performancegewinn gebracht. Nur ne Menge Serialisierungsarbeit (Serialisieren von Daten,Kommunikationsverwaltung) mehr.
    [/EDIT]


Anmelden zum Antworten