c++ tcp/ip usw....

[division]

Hallo,

ich möchte gerne ein kleines testprogramm schreiben mit c++ .net mit dem ich zwischen 2 Rechnern irgendwelche klamotten verschiken kann.

z.B.

Ich sende vom ersten rechner eine zahl oder string oder so was über einen port X an eine IP Y. Und was da ankommt schreibt er in eine datei oder auf die Konsole. Das ist aber eigentlich egal.

Kann mir mal jemand einen schubs geben..... Stehe da gerade auf der Leitung und die Ideen bleiben irgendwie aus?

Winsock???

Wäre über Hilfe dankbar.....

[Fruli-Tier]

Schnapp Dir die MSDN Library und such im .NET Framework nach der Socket Klasse.

OT
Warum nimmst Du eigentlich C++ mit .NET?

[Coda]

Vor allem C++ .NET - das ist eine jetzt schon tote Sprache. C++/CLI ist sehr viel besser.

[SimonX]

Warum nicht gleich das Orginal?!

C++ (ohne irgendwas) mit socket-library.

Die ganzen Kommunikations-Libraries oder -Packete sind viel zu allgemein und zu kompliziert, wenn es ins Eingemachte geht.

Zür eine TCP/IP Kommunikation braucht man folgende Funktionen:
bind()
connect()
socket()
write()
read()
und ganz wichtig poll().

Man definiere sich ein Protokoll, was aus einem Header mit fester Länge besteht, der die Länge der Daten definiert (z:B. ganz einfach als Zahl mit führenden Nullen), und aus den eigentlichen Daten, die beliebig sein können.

Zum Versenden baut man sich einen Buffer auf mit Header und Daten und sendet die mit write() über den Socket. Zum Empfangen liest man erst den Header mit der bekannten Länge und dann die eigentlichen Daten, deren Länge man aus dem Header ersehen kann.

Generell ist TCP/IP ein Stream. Es gibt also keine Packete die vom Sender zum Empfänger kommen, sondern ist gibt einen Stream von Daten, die beim Empfänger in ganz anderen Blöcken empfangen werden als vom Sender versendet. TCP/IP garantiert aber, das die Reihenfolge der Bytes immer richtig ist und das keine Bytes mitten drin verloren gehen. Wenn man also eine festen Header definiert hat, dann kann man so lange warten bis man ihn vollständig gelesen hat. Dann ist auch klar wieviel nachfolgenden Daten die Message noch hat.

Optimieren kann man das Empfangen durch einen einfachen generischen Buffer, so das man nicht für jede Message zwei read()'s machen muss, aber das ist am Anfang nicht notwendig. 2 read()'s sind auch nicht so teuer, da das Betriebssystem ja sowieso einen Buffer pro Socket bereitstellt, der normallerweise so 65k gross ist. (das kann man mit setsockopt noch individuell einstellen).

Um einen guten TCP/IP Server zu schreiben, der gleichzeitig mehrere Clients bedienen kann, muss man auch noch beachten, das man kein blockierendes reads() benutzt wenn man Messages empfängt, ausser vielleicht beim Header, der ja schön kurz sein sollte. Man sollte also pro client einen Messagebuffer haben, der die Teile der Message speichert, die bereits empfangen wurden und die gesammte Message erst dann an die übergeordnete Klasse gibt, wenn sie vollständig ist. BTW: Crc's oder sonstiges im Protokoll ist bei TCP/IP eine Verschwendung, das TCP/IP die Korrektheit der Daten garantiert. Falls natürlich falsche Daten gesendet wurden, so kann TCP/IP auch nicht helfen. Also sollte man nicht unendlich auf Daten von einem Client warten, wenn ein vollständiger Header empfangen wurde.

Das wesentliche Element im Server mit mehreren Clients gleichzeitig zu arbeiten ist poll(). Es erlaubt auf Events von mehreren sockets zu reagieren. So z:B. bekommt man ein Event wenn irgendwelche Daten an einem Socket anliegen und man kann dann diese Daten mit read() abholen.

Die meisten Kommunikations-Libraries oder -Frameworks verstecken diese Basisfunktionalitäten vor dem User, was für viele sicher der einfachere Weg ist. Nur lernt man durch Nutzung von solchen Frameworks nichts wirkliches. Man weiss nachher nur wie man das Framework benutzt und muss mit den, sehr oft, eingeschränkten Featuren dieser Frameworks leben. Auch macht man sich von solchen Frameworks abhängig und wenn irgendwann diese Frameworks nicht mehr gewartet werden dann steht man echt auf dem Schlauch. Das ist uns z.B. mit der libwww passiert, die ja nichtmehr von w3c gewartet wird. Zurecht, denn wir mussten uns durch deren drecking Code durchgraben um so manchen Bug zu beheben.

[Demirug]

Vor allem C++ .NET - das ist eine jetzt schon tote Sprache. C++/CLI ist sehr viel besser.

Ja, hat immer noch so seine Tücken gerade wenn man in die Grenzbereiche des IJWs (It Just Works) kommt. Ich habe letzte Woche 3 Tage "verschwendet" weil der Compiler Mist baut.

[Coda]

Dann soll er halt C# nehmen, aber doch kein C++ .NET X-D

[Gast]

Ja, hat immer noch so seine Tücken gerade wenn man in die Grenzbereiche des IJWs (It Just Works) kommt. Ich habe letzte Woche 3 Tage "verschwendet" weil der Compiler Mist baut.Ich habe mein halbes Leben daran verschwendet Assemblercode zu schreiben der besser ist als das was die verfügbaren Hochsprachencompiler hergaben ... also von daher alles ganz normal.

-zecki

@Topic ... mir ist unbegreiflich was die Frage mit der Sprachwahl zu tun hat, und warum man hier schon wieder über C# und ähnliches Geraffel reden muss.

Winsock (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/winsock_reference.asp)

[Demirug]

Ich habe mein halbes Leben daran verschwendet Assemblercode zu schreiben der besser ist als das was die verfügbaren Hochsprachencompiler hergaben ... also von daher alles ganz normal.

-zecki

Es geht nicht um besser sondern darum das er schlicht und ergreifend Code baut der überhaupt nicht funktioniert. Der Code reist sogar den Debugger mit runter.

@Topic ... mir ist unbegreiflich was die Frage mit der Sprachwahl zu tun hat, und warum man hier schon wieder über C# und ähnliches Geraffel reden muss.

Winsock (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/winsock_reference.asp)

Die Sprachwahl spielt da schon eine Rolle weil sobald man sich im .Net Umfeld bewegt eben nicht mehr Winsock sondern die entsprechenden TCP/IP Stream bzw UDP Datagram Klassen nimmt.