suche gute Socket Library
-
hi. schrieb:
Für C++ gibt es momentan noch keine guten Socket-Libraries.
Noch? Noch? Wie lange gibt es C++ schon? Wird es für C++ irgendwann überhaupt jemals eine gute Socket-Bibliothek geben? Ich glaube nicht mehr daran.
-
Optimizer schrieb:
hi. schrieb:
Für C++ gibt es momentan noch keine guten Socket-Libraries.
Noch? Noch? Wie lange gibt es C++ schon? Wird es für C++ irgendwann überhaupt jemals eine gute Socket-Bibliothek geben? Ich glaube nicht mehr daran.
ich doch auch nicht :p
-
Optimizer schrieb:
hi. schrieb:
Für C++ gibt es momentan noch keine guten Socket-Libraries.
Noch? Noch? Wie lange gibt es C++ schon? Wird es für C++ irgendwann überhaupt jemals eine gute Socket-Bibliothek geben? Ich glaube nicht mehr daran.
das kann doch nicht so schwer sein. eine 'class sockstream' mit operator >> und << und dem ganzen c++ krempel hat bestimmt schon einer gebastelt
-
net schrieb:
Optimizer schrieb:
hi. schrieb:
Für C++ gibt es momentan noch keine guten Socket-Libraries.
Noch? Noch? Wie lange gibt es C++ schon? Wird es für C++ irgendwann überhaupt jemals eine gute Socket-Bibliothek geben? Ich glaube nicht mehr daran.
das kann doch nicht so schwer sein. eine 'class sockstream' mit operator >> und << und dem ganzen c++ krempel hat bestimmt schon einer gebastelt
klar. aber die libraries werden alle nicht mehr gepflegt. viele bauen sich eine eigene library und veröffentlichen sie auch, bringen sie dann aber nicht "zu ende".
also ich wäre ja dafür das wir hier im c++ forum zusammen eine entwickeln.
-
Optimizer schrieb:
hi. schrieb:
Für C++ gibt es momentan noch keine guten Socket-Libraries.
Noch? Noch? Wie lange gibt es C++ schon? Wird es für C++ irgendwann überhaupt jemals eine gute Socket-Bibliothek geben? Ich glaube nicht mehr daran.
Stabile und funktionierende Libraries gibt es ja zu hauf. Siehe ACE oder Netxx. !flame!Und die sind immer noch besser als der J*v*/*N*T Müll
!flame!Es geht eben darum, dass man das moderne C++ Feeling genießt und das gibt es noch nicht so lange. Sagen wir mal, seit 2002 verbreitet es sich immer stärker. Mit giallo/boost::socket gibt es ja schon etwas in die Richtung, das ist aber leider zZ Alpha
-
netxx ist so gut wie tot: http://pmade.org/site/show/Software
giallo/boost::socket ist imho tot.
-
Wir sollten vieleicht wirklich mal versuchen etwas eigenes zu machen, wir können ja das hier als Grundlage benutzen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-74038-and-highlight-is-socket+library.htmlKönnt sich noch jemand bezüglich meiner Frage mit den BIO-Funktionen von OpenSSL ein paar posts weiter oben beschäftigen?
-
FloFri schrieb:
Wir sollten vieleicht wirklich mal versuchen etwas eigenes zu machen, wir können ja das hier als Grundlage benutzen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-74038-and-highlight-is-socket+library.htmlDas ist aber auch nicht gerade das was man gemeinhin unter einer Socket-Library versteht. Das ist ein besserer Wrapper. Mir fehlt da irgendwo die Erweiterbarkeit, auch haperts wenn man ein weiteres OS unterstützen will ziemlich am Design. Außerdem unterstützt es irgendwie nur die absoluten Grundlagen der Socket-Library. Wo sind RawSockets? Wenn schon so HighLevel dann aber bitte auch ganz oben: Wo ist ein ClientManager?
MfG SideWinder
-
Wo sind RawSockets?
*lol*
-
client manager schrieb:
Wo sind RawSockets?
*lol*
Naja gut, so weit runter muss man dann auch nicht gehen können, wenns ja vor allem darum geht dem User das zu verschleiern. Aber ich stehe halt persönlich auf Libraries bei denen man zwar mit drei Methodenaufrufen alles am Laufen hat aber im Notfall nahezu alles durch eigene Module austauschen kann um an die untersten Regionen auch zu kommen
MfG SideWinder
-
man kann ja erstmal nen guten wrapper bauen und darum baut man dann im zweiten schritt das high-level zeug
-
kingruedi schrieb:
Stabile und funktionierende Libraries gibt es ja zu hauf. Siehe ACE oder Netxx. !flame!Und die sind immer noch besser als der J*v*/*N*T Müll
!flame!Genau, und weil es für C++ so viele tolle Libs gibt, ist es auch immer meine erste Wahl für die Anwendungsprogrammierung.
ACE ist kostenpflichtig, oder? boost ist seit ungefähr 2-3 Jahren alpha und damit IMHO tot.
-
communityprojekt schrieb:
man kann ja erstmal nen guten wrapper bauen und darum baut man dann im zweiten schritt das high-level zeug
Ja, das ist die richtige Vorgehensweise. Siehe dazu auch (wenn es euch nicht zu sehr kränkt) das Design in der .Net Klassenbibliothek. Es gibt einen Raw-Socket-Wrapper, den man benutzen kann, wenn man auf Schmerzen steht. Dann gibt es einen TcpClient/TcpListener, der dieses Ding wrappt und Stream I/O bereitstellt. Außerdem sind hier noch ein paar Sachen wie Protokoll-Auswahl vorweg genommen (es gibt auch entsprechend nen UdpClient). Und natürlich ist hier ne Unterscheidung zwischen Server-/Client Sockets, die bei Raw Sockets bekanntlich nicht so gegeben ist.
Wiederum darauf aufbauend findet man dann Dinge wie Remoting.
Der einzige echte Designfehler ist, dass man jeweils an die eingekapselten Objekte ran kommt. Man kann von nen Remoting-Sink den TcpClient getten und von den den Raw-Socket-Wrapper. Dies hätte ich nicht zugelassen.
-
ACE ist glaubt ich nicht kostenpflichtig, aber es gibt keine kostenlose Dokumentation. Die Doku muß man sich in Form eines Buches kaufen. Das Geld wird also mit dem Buch gemacht und man kann die ACE-Entwickler als Berater einkaufen. Insofern wird ACE auch nicht einfacher benutzbar gemacht werden.
Die CommonC++ Lib von GNU hat doch so viele Socketklassen. Ich bin leider keiner der Sockets benötigt und hab es entsprechend noch nicht getestet. Der Nachteil an CommonC++ ist die GPL Lizenz.
-
Der Nachteil an CommonC++ ist die GPL Lizenz.
Der zweite Nachteil ist der, das es von Noobs programmiert worden ist.
-
Irgendwie schon nen Armutszeugnis für C++. Wenn ich mir da die .NET Socket Lib ansehe
-
wxWidgets
-
Entwickler78 schrieb:
Irgendwie schon nen Armutszeugnis für C++. Wenn ich mir da die .NET Socket Lib ansehe
Willst du es nicht verstehen ? C++ ist eine standartisierte Sprache. .Net ist M$-Scheisse. Eine Standartisierte C++ Socket lib müsste auf ALLEN Plattformen gleich funktionieren. Versuche einmal etwas zu standartisieren das auch auf Windows funktioniert. Bei der nächsten Win-Version beginnst du wieder von vorne. Da liegt das Problem.
Kurt
-
Bei der nächsten Win-Version beginnst du wieder von vorne.
??
-
Zuk! Ich glaub du verstehst nicht.
.NET ist sehr wohl standardisiert bei der ECMA und somit keine M$-Sch***. Ich weiß jetzt nicht ob die .NET-Sockets in der ECMA drin sind, aber bevor man über MS herzieht, nur weil es MS ist, sollte man sich über .NET informieren.Außerdem ist .NET hier nicht das Thema.