[C++] Netwerkprogrammierung

[daemon777]

Hallo,

ich wollte mal wissen ob mir jemand erklären kann wie ich unter C++ TCP/IP Protokolle verschicken bzw. auffangen kann. Das ganze sollte nicht zu schwer und unter der Microsoft Visual C++ Entwicklungsumgebung möglich sein

Bin mir sicher da gibts was ^^

Das ganze sollte dann irgendwann auf einen Chat und eine FTP verbindung hinauslaufen. Währe ganz schön wenn mir jemand von euch etwas darüber erzählen bzw. mir ein Tutorial schicken könnte.

Danke schon mal

 

[Arnd]

Hallo daemon777,

unter

http://www.w3.org/Protocols/rfc959/

findest Du die "original" Dokumentation zu FTP. Bzgl. Chat bin ich nicht so bewandert.

Im Wesentlichen beschränkt sich das FTP Protokoll darauf das zwei Sockets aufgebaut werden.

Eine Steuerverbindung und bei Bedarf eine Datenverbindung.

Über die Steuerleitung gehen die Klartextkommandos wie Dir, etc ... über die Datenverbindung gehen dann die Daten.

Tutorial kenne ich jetzt keins, ich habe mich durch den RFC gewühlt.

Aber in der Onlinehilfe zur MFC gibt es auch Beispiele für FTP. Einfach mal im Index FTP eingeben. Im VS2003 kommt da ein komplettes Beispielprogramm.

MfG

Arnd

 

[Boron]

http://www.zotteljedi.de/ -> Texte und Doku -> Tipps zur Socket-Programmierung

Das ist die beste deutschsprachige Anleitung, die man im Netz bekommen kann.
Das funktioniert unter nahezu allen Betriebsystemen.

Der Code, der gezeigt wird, ist zwar reines C, aber er lässt sich auch mit einem C++ Compiler übersetzen. Das stellt also für dich kein Problem dar.

Ich wiederhole:
Was Besseres gibt es nicht.
Jeglicher Versuch von diversen Klassenbibliotheken (MFC, Qt, Java-Lib) die Funktionalität in Klassen zu verpacken ist zwar gut gemeint, aber es geht irgendwie immer Klarheit und Funktionalität verloren.

"Nutze die Macht" und die Codebeispiele dieser Seite!

 

[7H3 N4C3R]

Japps Borons Seite ist nicht schlecht für den Anfang. Direkt auf der Socket-API zu arbeiten ist immer am Besten und verschafft gutes Verständnis darüber, was hinter den Kulissen abgeht.
Allerdings, Gold ist die Seite auch nicht =) Beim flüchtigen Lesen fallen mir schon die ersten Fehler in die Augen. So senkt close z.B. nur den Referenz-Zähler eines Sockets. (Der Deskriptor kann zwischen mehreren Prozessen geteilt werden, z.B. nach einem fork) Erst wenn der Referenz-Zähler 0 ist, wird der Socket geschlossen.

 

[Boron]

http://www.rt.com/man/close.2.html
Da kann ich deinem Beitrag nicht ganz folgen :.

 

[ghorst]

unter unix erhalten kinder (also prozesse dir mit fork erzeugt werden) alle datei und socket und sonstige descriptoren. daher ist die aussage close schließt einen solchen etwas irreführend. es stimmt vielmehr: close schließt diesen für den prozess, in dem der close-befehl aufgerufen wird, nicht aber generell. wenn du also mit open einen aufmachst, dann fork aufrufst und anschließend close, ist der descriptor für deine prozess zu aber für den geforkten ist er immer noch da. (insofern du mit exec ein neues binary geladen hast... sonst mach schließlich beide prozesse das gleiche.... )

 

[Arnd]

Zitat von zotteljedi.de

Client bleibt "kleben", Server lässt nicht los

- Bei fork an close in allen Prozessen gedacht?
- Irgendwelche vergessenen Aufrufe von dup, dup2 oder fdopen?

Zitat Ende

Ist unter "Die Scheisse geht net!" zu finden.

MfG

Arnd

 

[7H3 N4C3R]

Hm da hast Du recht, Arnd. Allerdings ist es gut versteckt.

Was aber z.B. trotzdem fehlt ist, dass man einen Socket nach einem fehlgeschlagenen connect schließen und neu erstellen muss, weil der (? .. die Socke) Socket danach ungültig geworden ist.

Als absolute Referenz für das Thema Sockets und UNIX kann ich nur das Buch "UNIX Network Programming Vol. 1, The Sockets Networking API" empfehlen. Sehr viel ausführliches Wissen, das sich zu sehr großen Teilen auch auf Windows übertragen lässt. Allerdings braucht man für das Buch schon recht gute C und zumindest grundlegende UNIX-Kenntnisse. Wie ich sehe, wird dieses Buch auch in Borons Link empfohlen. Und die Beschreibung ist wirklich nicht übertrieben =)


Nochmal zum ersten Post:
Lass die Finger von den MFC-Socketklassen. Die sind Müll. Gaukeln dir z.B. synchrone Übertragung vor (blocking/non-blocking), machen im Hintergrund aber alles über asynchronen I/O und Messages (ist zwar programmiertechnisch sinnvoll, weil man einen Thread mit Messageloop nicht blocken darf, aber es ist "was anderes drin als draufsteht"). Außerdem blieben mir die MFC-Klassen nach einiger Zeit reproduzierbar hängen - allerdings aus einem mir nicht verständlichen Grund. Daher habe ich davon die Finger gelassen. Ist besser so =)

 

[Arnd]

Von den MFC Klassen kann ich auch nur abraten. Den Weg über den RFC halte für den sinnvollsten, da man dabei am meisten lernt.

Nur da wird halt der Anspruch von einfach und schnell nicht erfüllt. Bis man so einen RFC oder eben auch ein Buch verstanden und durchgearbeitet hat, vergeht schnell mal ein Monat oder mehr.

Aber was gibt es schon umsonst :-).

MfG

Arnd