Warum ist System.Net.Sockets.Socket abgefuckt?





  • 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