3. Netzwerkprogrammierung auf C oder C++?

Netzwerkprogrammierung auf C oder C++?

  • S

    Hi Leute!

    Heute schreibe ich euch das erste mal in dieser Community und freue mich darauf euch kennen zu lernen und mit euch zusammen zu lernen und erklären 🙂

    Doch nun zu meiner Frage.

    Ich habe 2 Bücher. Einmal "C von A bis Z" und "C++ von A bis Z" doch leider ist dort nur die Einführung in die Netzwerkprogrammierung. Nun möchte ich mich aber gerne mit der Thematik mehr auseinander setzen und hoffe das ihr mir vieleicht sagen könnt mit welcher der beiden Sprachen ich besser für die Netzwerkprogrammierung gerüstet bin.

    Achso... die Plattform soll MS-WIN sein. Unix haben leider zuwenig Leute die ich kenne 🙂

    Bin auch noch Anfänger in sache Netzwerkprogrammierung!

    LG

    Santa

    0
  • S

    also erstens: beide bücher sind müll, selbst als klopapier gibt es besserere alternativen als diese bücher... (google mal hier im forum nach J.W., also dem autor)

    zweitens: ich persönlich kann dir nur sagen, machs mit der sprache die dir mehr leigt und besser gefällt. aber da du hier in einem C++ Forum bist, ist C++ auch die nummer 1 hier...

    0
  • K

    Zu empfehlen: http://beej.us/guide/bgnet/ wobei der Unterschied zwischen Windows und Unix nur WSAStartup sein sollte.

    0
  • C

    knivil schrieb:

    wobei der Unterschied zwischen Windows und Unix nur WSAStartup sein sollte.

    Nja, nicht ganz. Unter Windows ist der Typ von einem Socket unsigned, unter Unix signed. Zudem nimmt Windows bei send()/recv() const char*/char* bzw. int, unter Unix const void*/void* bzw. size_t. Zudem nutzt man unter Windows closesocket(), unter Unix close(). (Und WSACleanup() gibt's auch noch. :D)
    Es gibt auch noch Unterschiede bei getsockopt meine ich, weiß aber gerade kein Beispiel.
    Grundsätzlich gibt es da also schon Unterschiede, aber im Großen und Ganzen wirst du wohl durch ein paar typedefs den selben Code auf Linux/Mac/Windows nutzen können.

    Ach ja, die Frage war ja ob du dafür C oder C++ nutzen solltest. Na ja, wo würden denn hier die Vorteile von C++ liegen? Objektorientierung, Streams, Templates, ..
    Alles nur Abstraktion. Das hilft dir vielleicht dabei eine schöne Bibliothek zu bauen, aber letztendlich musst du dann mit Netzwerkprogrammierung und mit der Sprache an sich gleichzeitig kämpfen. Das würde ich nicht machen, erst mal will man doch nur ein bisschen senden und empfangen - das kannst du genau so gut mit C.
    (Und klar kannst du das in C++ Dateien setzen und sagen, dass das jetzt C++ ist. Aber ich denke das ist eh klar und es ging hier um den Stil.)

    0
  • S

    Danke erstmal an eure Beiträge zu meiner Frage.

    So wie ich es verstanden habe aus dem letzten Beitrag ist es also egal im großen und ganzen mit welcher Sprache ich das mache.

    Verbindung aufbauen und dann einfach durchhauen was geht. Ob mit OOP oder mit C. Wurst... richtig?

    0
  • 3

    Nimm boost::asio. Ist einfach zu verwenden und nicht so viel Arbeit für den Programmierer.

    P.S.: Ich seh schon cooky, wie er mich am liebsten erschlagen würde. Nur weil du asio nicht kennst!

    0
  • T

    314159265358979 schrieb:

    Nimm boost::asio. Ist einfach zu verwenden und nicht so viel Arbeit für den Programmierer.

    P.S.: Ich seh schon cooky, wie er mich am liebsten erschlagen würde. Nur weil du asio nicht kennst!

    asio ist leider arg schwer zu durchdringen, wenn man nicht schon mit besser Dokumentierten Netzwerk-APIs gearbeitet hat.

    0
  • C

    santa1982 schrieb:

    Wurst... richtig?

    Wenn das Ziel ist Netzwerkprogrammierung zu lernen: Ja. Mach es dir nicht unnötig schwer. Wenn du das dann verstanden hast und ein Programm machen möchtest, dass das Netzwerk nur als notwendiges Übel missbraucht, kannst du immer noch gucken, ob du dir eigene Socket Klasse baust oder irgendeine Bibliothek dafür verwendest.

    0
  • 3

    Das ist leider richtig. Aber zumindest eine grundlegende Einführung gibts hier: http://www.highscore.de/cpp/boost/asio.html#asio_netzwerkprogrammierung

    0
  • K

    314159265358979 schrieb:

    P.S.: Ich seh schon cooky, wie er mich am liebsten erschlagen würde. Nur weil du asio nicht kennst!

    Hoere einfach auf, Leuten Worte in den Mund zu legen.

    0
  • 3

    dudewhat

    0
  • ?

    Pi macht sich mal wieder lächerlich 🙄

    0
  • P

    Back to topic. Alle. Kein "der hat angefangen", kein geflame mehr. Sind doch nicht im Kindergarten hier.

    0
  • E

    Asio ist das Allerletzte für Anfänger. Asio ist overengineered und viel zu mächtig.
    Einfach n bischen die BSD/POSIX/Windows Sockets wrappen (das schreit doch nach ner Klasse 'Socket') und los gehts. 😉

    0
  • J

    > (das schreit doch nach ner Klasse 'Socket')

    Das schreit nach Bufferoverlows und noch mehr Netzwerk-Exploits, weil immer wieder von vorne das selbe programmiert wird und dabei (besonders bei recv()) dramatische Fehler gemacht werden. asio ist nicht overengineerd und schon garnicht zu mächtig. Hast du z.B. schon mal auf echter API mit Dual Stack Sockets gearbeitet? Weißt du wie viel Aufwand das ist? Weißt du, dass heutzutage Anwendungen ohne IPv6-Kompatibilität dumm sind? Ein _gutes_ Netzwerkprogramm in reiner API ist so schwer zu schreiben und zu debuggen, dass man besser Bibliotheken nutzt.
    An asio stoßen sich viele Anfänger die Köpfe, weil Codeteile eben parallel (sprich asynchron) ablaufen, Threadsicherheit eine Rolle spielen kann etc. Aber es gibt noch sehr viele andere gute (und evtl. leichtere, wenn auch weniger performant und allgemeinnützlich), z.B. Poco.Net

    0
  • ?

    Jodocus schrieb:

    > (das schreit doch nach ner Klasse 'Socket')

    Das schreit nach Bufferoverlows und noch mehr Netzwerk-Exploits, weil immer wieder von vorne das selbe programmiert wird und dabei (besonders bei recv()) dramatische Fehler gemacht werden.

    Vollkommen richtig, zum Lernen kann es aber trotzdem sinnvoll sein, hängt imho vom Typ Mensch ab 🙂

    0
  • E

    Er möchte lernen und nicht zwingend gleich eine voll ausgestattete Anwendung schreiben. Und wie das Ganze funktioniert lernt man doch deutlich besser mit den Low-Level Sockets, er kann ja immer noch auf Asio wechseln.

    Und so schwer ist es wirklich nicht, das ganze sicher zu machen.

    0
  • C

    Jodocus schrieb:

    Das schreit nach Bufferoverlows und noch mehr Netzwerk-Exploits,

    Genau, denn er wird bestimmt gleich ein relevantes Netzwerkprogramm schreiben, für das dann Exploits entwickelt werden.

    Jodocus schrieb:

    weil immer wieder von vorne das selbe programmiert wird und dabei (besonders bei recv()) dramatische Fehler gemacht werden.

    Jau, bei recv() kann man super viel falsch machen. 😃

    0
  • E

    Dann werde ich mich mit Heldenmut dafür einsetzen dass durch recv keine Bufferoverflows mehr geschehen.

    std::vector<char> read_socket(int sock, std::size_t amount)
{
   std::vector<char> buffer(amount);

   std::size_t read_total = 0;
   while(read_total != amount)
   {
      int this_read = recv(sock, &buffer[0] + read_total,
         buffer.size() - read_total, MSG_WAITALL);
      if(this_read == -1)
         throw std::runtime_error("socket recv error");
      if(this_read == 0)
      {
         buffer.resize(read_total);
         break;
      }

      read_total += this_read;
   }

   return buffer;
}

    Verflixt war das schwer.

    0
  • J

    > Er möchte lernen und nicht zwingend gleich eine voll ausgestattete Anwendung schreiben.

    Aber er möchte das lernen, um sowas zu machen. Was denkst du, wo die Exploits in den "großen Anwendungen" herkommen? Genau, weil Leute dachten, sie hätten es in ihren Spielchen verstanden und dann Software "fürs echte Leben" geschrieben haben.

    > Und wie das Ganze funktioniert lernt man doch deutlich besser mit den Low-Level Sockets, er kann ja immer noch auf Asio wechseln.

    Ist genau die selbe Logik in der "Zuerst C-Strings oder C++-Strings"-Debatte. Und ich bleibe dabei. Besser erst C++-Strings, besser erst eine Socket-Abstraktionsebene höher. Sich vertiefen kann man immernoch, wenn man es braucht. Dann kann man auch eine eigene Abstraktion schreiben und die Low-Level-Sachen durchprogrammieren, um zu sehen, wie sie funktioniert aber dann wieder die fertige und gut getestete Library nehmen (wie bei std::string). Und Socket-Librarys verschleiern GANZ sicher nicht die Socket-Semantik. Sie vereinfachen lediglich die API. Wenn 5 von 8 Funktionsparametern für einen Anfänger nicht relevant sind (z.B. QoS, diverse Flags etc.), dann hilft ihm das nicht, Sockets zu verstehen. Es geht schließlich ums wesentliche, und gute Library-Interfaces nötigen einen nichts unwesentliches auf, behalten dem Programmierer aber auch keine Details vor, wenn sie sie benötigen.

    > Genau, denn er wird bestimmt gleich ein relevantes Netzwerkprogramm schreiben, für das dann Exploits entwickelt werden.

    Gleiches wie oben. Manche dachten, sie hätten recv() und deren Rückgabewert verstanden und programmierten damit dann "echte" Software.

    > Jau, bei recv() kann man super viel falsch machen. 😃

    Ich hoffe dass das keine Ironie war.

    0
Anmelden zum Antworten