C++: Sockets / WinAPI(TCP/IP)

[Nightshift]

Hi,

wollte mich in nächster Zeit mal an einem (C++) Programm mit Datenübetragung über TCP/IP ausprobieren.
Das Problem ist nur, dass es schwierig ist gute Dokumentationen, Bücher oder insgesamt gute Literatur zu finden.
Ich habe zwar im Internet hier und da ein bisschen was an Tutorials gefunden, aber ein richtig gutes Buch zum Thema Sockets und/oder WinAPI (für TCP/IP) (Deutsch oder englisch) würde ich dennoch bevorzugen.

Hat da jemand einen guten Tip für mich?

 

[Terminatrix]

Habe letzte Woche das erste Testprogramm für TCP/IP in der Schule geschrieben/erweitert. Ich kanns ja vllt. mal heute abend hier reinstellen. Ist allerdings C#!

 

[Lynxeye]

So schwer ist das ganze gar nicht. Mit den Tutorials kann man schon sehr weit kommen. Und wenn dann noch Fragen auftauchen gibts zu fast allem schon in irgend einem Forum ne Antwort.
Bücher gibts da an Grundlagenwissen einzeln nicht viel, da man damit kein Buch vollbekommen würde. Deswegen werden da immer spezielle Themen behandelt.
Die Tutorials von C-Worker sind zwar inzwischen leicht veraltet, aber für den Einstieg immer noch zu empfehlen.

 

[Nightshift]

Ok, danke euch schon mal für die Antworten. Hab schon kürzlich einige Tutorials rausgesucht, werde mich dann erstmal mit denen beschäftigen.

Tips zu "greifbarer" Literatur sind aber weiterhin willkommen, kann z.B. auch einfach ein Buch zur WinAPI insgesamt sein in dem auch das Handling mit TCP/IP beschrieben wird.
Das Buch sollte dann nur auch insgesamt gut genug sein.

 

[Lynxeye]

Sockets haben auch unter Windows nicht viel mit der WinAPI zu tun. Außer das man unter Windows noch die Winsock DLL initalisieren muss sind die Unterschiede nur sehr gering. Der Berkley Socket Standard gilt auf UNIX Systemen genauso wie auf Windows. Deshalb unterscheidet sich die Programmierung da fast überhaupt nicht, weshalb das auch genau nix mit der WinAPI zu tun hat.

 

[flybyray]

Tips zu "greifbarer" Literatur sind aber weiterhin willkommen, kann z.B. auch einfach ein Buch zur WinAPI insgesamt sein in dem auch das Handling mit TCP/IP beschrieben wird.

ACE

Diese Programmiertools sind alle unter der Leitung von Douglas C. Schmidt entstanden und sind Opensource.

Auch sehr bekannt TAO. Eine realtime CORBA implementierung.
Dieser Prof hat auch einige gute Bücher geschrieben bzw. ist Co-Author.

1:
Schmidt, Douglas C.: C++ network programming - Volume 1: Mastering Complexity with ACE and Patterns
2:
Schmidt, Douglas C.: C++ network programming - Volume 2: Systematic reuse with ACE and frameworks

Ein weiteres von dem Professor empfohlenes Buch ist.
3:
Huston, Stephen D.: The ACE programmer's guide

Das 1. Buch beschreibt auch die Socket API. Diese ist tatsächlich weitestgehend unabhängig vom Betriebssystem. Hier werden auch die Schwächen dieser Socket API aufgezeigt.
Leider weiß ich nicht ob das Buch auch ins Deutsche übersetzt verfügbar ist.


Die Frameworks sind wirklich extrem gut in bestehende (häufig verwendete) Entwicklungsumgebungen zu integrieren wegen der Verwendung von The Makefile, Project and Workspace Creator. Also auch mit Visual Studio 2005/2008 gut zu verwenden.

 

[Nightshift]

@ Lynxeye:
Ich weiß, ich frage aber gezielt nach beidem weil ich bei einer Lösung für Windows-BS gucken kann ob mir die Lösung mit Windows-API besser gefällt als ein Ansatz über Sockets.
Und Sockets auf der anderen Seite würden bei der Portabilität des Codes helfen.
Hab verschiedene Ideen und je nachdem was ich umsetze wäre es gut wenn mein Code ohne große Verrenkungen auch auf Linux-Systemen läuft.

@ QlX39k0tFGSI4d70vdZq:
Danke Dir, werde ich mir mal genauer ansehen. Ist egal ob die Bücher auf Deutsch oder Englisch sind.

 

[flybyray]

Und Sockets auf der anderen Seite würden bei der Portabilität des Codes helfen.

Also das ACE Framework ist jedenfalls sehr gut portierbar auf ungewöhnlichste Architekturen. Aber schau dir doch auch mal einfach Qt und seine Netzwerk API an.

Hab verschiedene Ideen und je nachdem was ich umsetze wäre es gut wenn mein Code ohne große Verrenkungen auch auf Linux-Systemen läuft.

Welche Ideen hast du denn? Ich denke für die meisten Sachen reichen die einfachen Bibliotheken von Qt vollkommen aus. Außerdem bietet Qt nützliche Beispiele und ist auch leicht portabel. LINK auf Weblinks in Wikipedia

@Nightshift: Hab dich bei POEM überholt! :-D

 

[Nachtschicht]

Also das ACE Framework ist jedenfalls sehr gut portierbar auf ungewöhnlichste Architekturen.

Na, da möchte ich mal gern mal die Windows-Portierung für die UNIX-Signale sehen:
http://www.cs.wustl.edu/~schmidt/signal-patterns.html

Den Sinn von ACE hatte ich noch nie verstanden, wozu braucht man das, wenn man UNIX-Systemprogrammierung kann?

Ich musste mal vor Jahren beruflich ein kommerzielles Produkt von Orbacus (Corba) auf TAO (aus dem gleichen Haus wie ACE) umstellen. Das wahr sehr schmerzhaft. TAO ist ein typisches Uni-Projekt, da darf jeder Student mal etwas programmieren.

Zum Thema: In der UNIX-Welt sind die Bücher von Stevens "Network Programming" das Standardwerk für IPC, auch mit sehr viel Socket-Kram, aber für UINIX.
http://www.amazon.de/Unix-Network-P...ie=UTF8&s=books-intl-de&qid=1233942517&sr=8-1

Windows macht im Detail einige Sachen anders, aber der anerkannte Stand der Technik ist seit 30 Jahren ganz sicher die UNIX-Welt. Wenn man es richtig wissen will, dann Linux (UNIX), zum Lösen einer Aufgabe reicht das Windows-API.

Natürlich ist pure Socket-Programmierung schon etwas angestaubt, aber gerade im embedded Bereich wird noch viel damit gemacht.

 

[flybyray]

Na, da möchte ich mal gern mal die Windows-Portierung für die UNIX-Signale sehen:
http://www.cs.wustl.edu/~schmidt/signal-patterns.html

Die Portierung kannst du dir gerne im Source ansehen. Leicht verständlich ist es aber nicht. Eine Einstiegshilfe ist die Klasse ACE_Event_Handler.
Die Verwendung ist aber denkbar einfach durch Ableiten von dieser Klasse.
Dazu ein Zitat aus dem Buch The ACE Programmer´s Guide.

As allways, ACE provides us with a nice, clean API portable across dozens of operating systems. Handling signals is as simple as defining a class derived from ACE_Event_Handler with your code in it the new handler class´s handle_signal() method and then registering an instance of your object with one of the two appropriate register_handler() methods.

Den Sinn von ACE hatte ich noch nie verstanden, wozu braucht man das, wenn man UNIX-Systemprogrammierung kann?

Na klar es kommt immer darauf an was du machen möchtest! ACE steht für ADAPTIVE Communication Environment. Und dieser Titel/Name ist nicht nur Schall und Rauch sonder sollte auch wirklich so verstanden werden. ACE versteckt die Komplexität von unterschiedlichen/heterogenen Umgebungen und bietet dennoch die best mögliche Flexibilität für die Anwendung und reduziert dabei nicht die Leistung und Skalierbarkeit des Systems. Douglas Schmidt hat mit dem ACE Programmiertoolkit eine ernsthaft durchdachte effiziente Lösung für Netzwerkkommunikation geschaffen.
Letztendlich verwendet die ACE API auch UNIX-Systemprogrammierung, jedoch geht es bei der API mehr um die Muster/Designpatterns die es verwendet um die Komplexität zu beherschen und effiziente Möglichkeiten anzubieten.
Selbstverständlich ist es aufwendig sich in eine API einzuarbeiten, anders ist es auch nicht bei der ACE API.
Für die schnelle zusammen gebaute/gefrickelte Netzwerkkommunikation gibt es einfache Lösungen. ES KOMMT DARAUF AN WAS MAN MACHEN MÖCHTE!!!

Ich musste mal vor Jahren beruflich ein kommerzielles Produkt von Orbacus (Corba) auf TAO (aus dem gleichen Haus wie ACE) umstellen. Das wahr sehr schmerzhaft. TAO ist ein typisches Uni-Projekt, da darf jeder Student mal etwas programmieren.

Da hast du teilweise Recht! Teilweise? Ja teilweise! Denn der Kern von TAO (CORBA) ist definitiv kein Werk von Studenten und basiert auf der ACE Api! Was Studenten wirklich gemacht haben kann man nicht so pauschal sagen. Wo Studenten bei der Entwicklung mitgewirkt haben sind einige der vielen CORBA-Services. Wobei die Zeitkritischen und CORBA-essentiellen Services auch durch fachkundige Menschen entwickelt worden sind.
Das TAO und ACE nicht nur "blödsinn" sind belegt bestimmt auch die Liste der Benutzer von TAO und ACE.

ACE und ich denke auch TAO hat seine Daseinsberechtigung schon lange bewiesen. Ob es für die eigene Anwendung sinnvoll ist sich in diese API einzuarbeiten ist eine andere Sache. Jedenfalls würde ich behaupten, dass es das Wert ist wenn man sich die Konzepte von ACE einmal ansieht. Und bestimmt gibt es andere "Werke" die auch gut sind (für ihren Anwendungsbereich).

 

[Nachtschicht]

Da hast du teilweise Recht! Teilweise? Ja teilweise! Denn der Kern von TAO (CORBA) ist definitiv kein Werk von Studenten und basiert auf der ACE Api! Was Studenten wirklich gemacht haben kann man nicht so pauschal sagen. Wo Studenten bei der Entwicklung mitgewirkt haben sind einige der vielen CORBA-Services. Wobei die Zeitkritischen und CORBA-essentiellen Services auch durch fachkundige Menschen entwickelt worden sind.

War ein bißchen flapsig formuliert: Seriös klingt es so: Die Qualität des freien ACE-basierten TAO war deutlich geringer als die des kommerziellen (open source) Orbacus.

Für mich stellt sich immer noch die Frage, ob ACE mehr ist als eine überflüssige Hülle. Erstens ist ACE wohl auf *x-Systeme eingegrenzt, von Portierbarkeit wie bei qt, xerces, ... keine Spur. Provokativ: ACE ist das persönliche Hobby eines einzelnen Professors.

An welcher Stelle geht denn nun z.B. die Interprozesskommunikation bei ACE über den den sowieso verfügbaren Sun-RPC hinaus? Oder bauen die noch 3 Hüllen ums select() mit consumer und producer?

 

[flybyray]

An welcher Stelle geht denn nun z.B. die Interprozesskommunikation bei ACE über den den sowieso verfügbaren Sun-RPC hinaus? Oder bauen die noch 3 Hüllen ums select() mit consumer und producer?

Vielleicht sollten wir den weiteren "Sinn und Zweck von ACE" unter einem neuen Thema diskutieren (soll mal wer anders sagen!).
ACE macht die IPC-Mechanismen von UNIX/SUN/WINDOWS nicht besser! Soll es auch nicht!
ACE hilft hier Programmierschnittstellen zu vereinheitlichen. Klar kannst du da behaupten, dass es ja nur eine Hülle ist. Aber du solltest dich mal im Leben umschauen wie oft es Hüllen gibt die man nicht braucht! Da kommt aber noch der Begriff Delegation ins Spiel. Delegation ist ein trickreiches und nicht zu unterschätzendes Instrument (manche Manager/Politiker wissen auch wie man damit umgeht)!
Bei ACE dreht sich viel um Konzepte! Das habe ich schon früher betont. Unter der vereinheitlichten "Hülle" können (mittels der Delegation) ACE IPC Klassen (es gibt sinnvolle IPC Trennungskonzepte und selbst SUN hat einige entwickelt) ausgetauscht werden und somit einer veränderten Anforderung oder Leistung genügen.

PS: Bitte fange wirklich einen neues Thema an wenn du "Sinn und Zweck von ACE" weiter in Frage stellen möchtest. Ich habe niemanden gezwungen ACE zu verwenden. Es ist definitiv kein muss! Ich befinde es nur von seinen Konzepten her für lohnenswert sich das anzusehen.

ERGÄNZUNG: CPSM (Cross-Platform Support Middleware) (hier wird die "Hülle" sogar noch modelliert!