Clientsockets aus der vhlib

?

http://www.volkard.de/vhlib.rar

virtuell Realisticer

hier schrieb:

?

http://www.volkard.de/vhlib.rar

Ah, bin von dem anderen Link (neueVersion.rar) ausgegangen, danke

mfg
v R

volkard

virtuell Realisticer schrieb:

Ah, bin von dem anderen Link (neueVersion.rar) ausgegangen

damit es spannend bleibt, ändere ich schon wieder den dateinamen.
in http://volkard.de/vhlib.tar.bz2

zum einen packt .tar.bz2 besser als .rar, zum anderen sind bzip2.exe und tar.exe auch für win einfach zu beschaffen und ich brauche keine fallunterscheidung im makefile. und wie ich mir berichten ließ, haben die meisten unter win ja WinZIP oder WinRar oder sowas drauf, daß sie auch so schon .tar.bz2 lesen können.

neu:
cin und cout sind nicht mehr zwei objekte, sondern nur zwei referenzen auf die selbe konsole.

credits.cpp, wo ich aufliste, wer alles geholfen hat.

und die sache compiliert endlich wieder durch und liest und zeigt ne web-page an.

virtuell Realisticer

Zumindest von WinRAR weiss ich, dass es bz2 beherrscht.

Weisst du jetzt schon, wie du das mit den Sockets machen willst? Wenn ich mich
noch recht entsinne und so lange war es ja noch nicht her, dann wollteste
SocketServer auch nicht so recht. Also am besten fuer beides Socket.

Waere hier vielleicht ein Template angebracht? Also dass ich sowas schreibe:

Socket<Client> clientSocket;
Socket<Server> serverSocket;

Oder Sieht das eher bloed aus? Oder sollte das vielleicht doch ganz anders
genannt werden? Vielleicht TCPSocket und UDPSocket (ja udp haben wir ja auch
noch und so ganz selten wird es ja auch nicht genutzt)?

Nun aendert sich bei TCPSocket und UDPSocket ja nicht so wahnsinnig viel. Also
koennen wir auch dahergehen und sagen, ich gebe beim CTor an, welche Art von
Socket ich haben will.

Ich habe mal in meinem Abschlussprojekt ein Enum von Protokollen gemacht, so
dass der Enum auch der entsprechenden internationalen Protokollnummer
entspricht. Sicherlich auch einiges dabei, was man nicht brauchen wird, aber
wenn du magst, kann ich dir das mal zukommen lassen und du schaust es dir
einfach mal an.

Hab dafuer auch noch eine Klasse gemacht, die einen Protokollstring (z. B. TCP)
in den entsprechenden Enum mapped. Naja, das ist allerdings nicht so toll
programmiert ;).

Also falls du daran interesse hast, einfach kurz Bescheid sagen, dann schick
ich dir das und du kannst dir den grauenhaften Code mal anschauen :p.

Aber jetzt bin ich ja wieder vom Thema abgeschweift. Also eigentlich braeuchten
wir ja wirklich nur Socket, denn was macht denn ein ServerSocket anderes als
ein ClientSocket?

Nun der ServerSocket ruft nunmal kein connect, sondern bind und listen auf und
ausserdem macht er noch accept.

Und der ClientSocket, der ruft nur connect auf und recv und send machen beide.

Aber wie das nun gescheid trennen?

mfg
v R

volkard

virtuell Realisticer schrieb:

Waere hier vielleicht ein Template angebracht? Also dass ich sowas schreibe:
Socket<Client> clientSocket;
Socket<Server> serverSocket;

nee. das schmerzt mich. und es ist nix anderes als ClientSocket und ServerSocket.

Vielleicht TCPSocket und UDPSocket (ja udp haben wir ja auch
noch und so ganz selten wird es ja auch nicht genutzt)?

UDP biete ich bis auf weiteres gar nicht an. ich hab's noch nie gebraucht.

Nun aendert sich bei TCPSocket und UDPSocket ja nicht so wahnsinnig viel. Also koennen wir auch dahergehen und sagen, ich gebe beim CTor an, welche Art von Socket ich haben will.

ich denke, die schnittstelle ist schon sehr anders. aber ich mach eh keine UDP-sockets.

Ich habe mal in meinem Abschlussprojekt ein Enum von Protokollen gemacht, so dass der Enum auch der entsprechenden internationalen Protokollnummer entspricht.

win möchte eh, daß ich den port oder service-namen als string übergebe.

Socket s("192.168.1.1","http");

mal abwarten, was linux da zu bieten hat.

Hab dafuer auch noch eine Klasse gemacht, die einen Protokollstring (z. B. TCP) in den entsprechenden Enum mapped. Naja, das ist allerdings nicht so toll programmiert ;).

falls linux nicht sowas schon hat, kann ich den mapper brauchen, damit ich ne einheitliche schnittstelle habe. ich melde mich gegebenenfalls bei dir.

Aber jetzt bin ich ja wieder vom Thema abgeschweift. Also eigentlich braeuchten
wir ja wirklich nur Socket, denn was macht denn ein ServerSocket anderes als
ein ClientSocket?
Nun der ServerSocket ruft nunmal kein connect, sondern bind und listen auf und
ausserdem macht er noch accept.

ähm. das ist doch ein Riesenunterschied. dewr usewr darf doch nicht auf einem Clientsocket einfach mal accept aufrufen können.

Und der ClientSocket, der ruft nur connect auf und recv und send machen beide.

eigentlich gibt es drei sockets.
ClientSocket: macht connect
ServerSocket: wird von accept erzeugt
ListeningSocket: ist halt der, der am port lauscht und die ServerSockets erzeugt.

zusammenfassen konnte ich ClientSocket und ServerSocket gut. die haben nur verschiedene konstruktoren aber die haben << und >> gemeinsam und auch den gleichen destruktor (mit shutdown() und closesocket()).

der ListeningSocket ist ne eigene klasse, sie hat ja so vieles anders. anderer ctor, anderer dtor, keine op<< und op>>, aber dafür accept. alles ist da anders, außer ::socket() und ::closesocket().

und ich nehme als namen ListeningSocket oder SocketListener oder PortListener oder was weiß ich. egal, was ich jetzt nehme, in nem halben jahr ändere ich eh meine meinung wieder. *g*

aber die andere sorte nene ich einfach nur Socket. egal, ob der clientseitig oder serverseitig verwendet wird.

virtuell Realisticer

volkard schrieb:

virtuell Realisticer schrieb:
Waere hier vielleicht ein Template angebracht? Also dass ich sowas schreibe:
Socket<Client> clientSocket;
Socket<Server> serverSocket;
nee. das schmerzt mich. und es ist nix anderes als ClientSocket und ServerSocket.

Vielleicht TCPSocket und UDPSocket (ja udp haben wir ja auch
noch und so ganz selten wird es ja auch nicht genutzt)?

UDP biete ich bis auf weiteres gar nicht an. ich hab's noch nie gebraucht.

Was aber doch nicht heissen sollte, dass man dem User die Moeglichkeit es zu
benutzen verweigern sollte, oder? Wie leicht waeren die Aenderungen zu machen,
es nachtraeglich einzubauen?

Nun aendert sich bei TCPSocket und UDPSocket ja nicht so wahnsinnig viel. Also koennen wir auch dahergehen und sagen, ich gebe beim CTor an, welche Art von Socket ich haben will.

ich denke, die schnittstelle ist schon sehr anders. aber ich mach eh keine UDP-sockets.

Ich habe mal in meinem Abschlussprojekt ein Enum von Protokollen gemacht, so dass der Enum auch der entsprechenden internationalen Protokollnummer entspricht.

win möchte eh, daß ich den port oder service-namen als string übergebe.
Socket s("192.168.1.1","http");
mal abwarten, was linux da zu bieten hat.

Kein Problem: getservbyname bzw. getservbyport sind dein Freund :).

Hab dafuer auch noch eine Klasse gemacht, die einen Protokollstring (z. B. TCP) in den entsprechenden Enum mapped. Naja, das ist allerdings nicht so toll programmiert ;).

falls linux nicht sowas schon hat, kann ich den mapper brauchen, damit ich ne einheitliche schnittstelle habe. ich melde mich gegebenenfalls bei dir.

Was ja dank o. genannter Funktionen doch wieder unnoetig geworden ist :).

Aber jetzt bin ich ja wieder vom Thema abgeschweift. Also eigentlich braeuchten
wir ja wirklich nur Socket, denn was macht denn ein ServerSocket anderes als
ein ClientSocket?
Nun der ServerSocket ruft nunmal kein connect, sondern bind und listen auf und
ausserdem macht er noch accept.

ähm. das ist doch ein Riesenunterschied. dewr usewr darf doch nicht auf einem Clientsocket einfach mal accept aufrufen können.

Ja richtig, da hab ich nicht richtig nachgedacht.

Und der ClientSocket, der ruft nur connect auf und recv und send machen beide.

eigentlich gibt es drei sockets.
ClientSocket: macht connect
ServerSocket: wird von accept erzeugt
ListeningSocket: ist halt der, der am port lauscht und die ServerSockets erzeugt.

Ah ok, das hoert sich gut. Also ich kann dann sowas wie

ServerSocket servSock = listeningSocket.accept();

schreiben und dann schoen damit weiterarbeiten.
Aber: Unser bind und listen kommt dann natuerlich in ListeningSocket und nicht
in ServerSocket. ServerSocket ist hier nichts anderes als die Verbindung zum
Client, der eine Anfrage an den Dienst, auf dem ListeningSocket horcht,
gesendet hat. Also wenn dem so ist, dann ist ServerSocket auch wieder nur ein
Socket.

zusammenfassen konnte ich ClientSocket und ServerSocket gut. die haben nur verschiedene konstruktoren aber die haben << und >> gemeinsam und auch den gleichen destruktor (mit shutdown() und closesocket()).

Wenn du einen ListeningSocket hast, dann ist ClientSocket == ServerSocket, denn
bind und listen wird nicht vom ServerSocket gemacht und dieser bietet auch gar
kein accept an, sondern wird vom letzteren erzeugt. Wir haben also doch nur
einen normalen Socket, das andere erledigt ListingSocket.

der ListeningSocket ist ne eigene klasse, sie hat ja so vieles anders. anderer ctor, anderer dtor, keine op<< und op>>, aber dafür accept. alles ist da anders, außer ::socket() und ::closesocket().

und ich nehme als namen ListeningSocket oder SocketListener oder PortListener oder was weiß ich. egal, was ich jetzt nehme, in nem halben jahr ändere ich eh meine meinung wieder. *g*

Aber bis dahin haben wir ja noch ein bisschen Zeit :D.

aber die andere sorte nene ich einfach nur Socket. egal, ob der clientseitig oder serverseitig verwendet wird.

Ah, also doch nur zwei Klassen. Aber ich hoffe ich habe das gut nachvollzogen ;).

mfg
v R

Konrad

volkard schrieb:

damit es spannend bleibt, ändere ich schon wieder den dateinamen.
in http://volkard.de/vhlib.tar.bz2

zum einen packt .tar.bz2 besser als .rar, zum anderen sind bzip2.exe und tar.exe auch für win einfach zu beschaffen und ich brauche keine fallunterscheidung im makefile. und wie ich mir berichten ließ, haben die meisten unter win ja WinZIP oder WinRar oder sowas drauf, daß sie auch so schon .tar.bz2 lesen können.

Find Ich klasse, brauch mich endlich nicht mehr mit unrar rumquälen.

Was mich sonst noch interessieren würde ist, warum "baust" du die vhlib?
Das einzige was Ich mitbekommen habe ist das du die Std-Bibliothek nicht benutzen möchtest. Aber warum?
Erzähl mal ein bisschen, bitte.

Unter Linux gibts doch auch getaddrinfo und getnameinfo

virtuell Realisticer

v6 schrieb:

Unter Linux gibts doch auch getaddrinfo und getnameinfo

Stimmt, damit waeren wir auch protokollunabhaengig.

mfg
v R

Socket s("192.168.1.1","http");

ist es eigentlich irgendwo dokumentiert welche protokolle getaddrinfo kennt?

rüdiger

80 schrieb:

Socket s("192.168.1.1","http");
ist es eigentlich irgendwo dokumentiert welche protokolle getaddrinfo kennt?

Ich weiß nicht ob POSIX da etwas vorschreibt. Aber unter /etc/protocols kannst du die Protokolle einstellen.

volkard

Konrad schrieb:

Was mich sonst noch interessieren würde ist, warum "baust" du die vhlib?
Das einzige was Ich mitbekommen habe ist das du die Std-Bibliothek nicht benutzen möchtest. Aber warum?
Erzähl mal ein bisschen, bitte.

ich mag tolle sachen. und wenn etwas das prädikat "nicht toll" verdient hat, dann die standard-lib von c++.
bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting, der packer packt nicht mehr toll. dann der verzicht auf großbuchstaben mit der folge vermehrter namenskollission. das weglassen von get/set, womit kein arsch wissen kann, ob foo.begin() das foo anfangen läßt oder ob's den anfang zurückliefert. und das sind nur die offensichtlichsten sachen.
subtiler ist, daß die streams default-konstruktoren haben und lebende und zugleich ungültige zombie-streams existieren können. daß der default-ctor von vector keinen speicher allokiert, daß delete(0) legal ist, daß assert keine exception wirft, daß die streams hoffnungslos verkompliziert sind, daß vector nur freispeicher mag und damit prinzipiell zu lahm für kleine aufgaben ist, daß die baume aufwärtszeiger haben, daß man irgendwe immer wieder gezwungen wird, zeiger zu nehmen, wo man gar keine zeiger haben mag, sondern objekte, und daß man dann zu smart-pointers gezwungen wird und sich auf einmal fragt, warum das in C schneller ging.

ich mach mal das verzeichnis mit den standard-headers auf und meckere alle ab.
algorithm
jo, die ist gut. supi.

bitset
ist kein zufall, daß ich seit jahren ne eigene klasse BitField habe.

complex
naja, stört nicht.

template<typename _Tp>
    inline complex<_Tp>
    operator-(const _Tp& __x, const complex<_Tp>& __y)
    {
      complex<_Tp> __r(__x, -__y.imag());
      __r.real() -= __y.real();
      return __r;
    }

deque
die ist auch ganz ok.

exception
why gibt nen string aus, der irgendwie mit new speicher holt? oder einen char*, der vielleicht static ist? warum kann sich die exception nicht in einen stream schreiben und wer echt nen string haben muss, läßt sich in nen stringstream schreiben?

fstream
default-ctor. komische sachen wie ios::append. private erblichkeit für coole hacks. unduchsichtig. wer braucht eigentlich locales?

functional
ausgetobt mit exceptions, aber weitgehend ohne praktischen nutzen? ok, nehmen wir mal an, wir hätten wenigstens typeof verfügbar.

iomanip
entweder klickibunti oder konsole unformatiert. iomanip zum formatieren braucht man eigentlich nicht. was macht iomanip noch?

ios

iosfwd
daß <iosfwd> nötig wurde, sagt was über andere headers aus.

iostream
eigentlich ein sehr komischer name für eine datei, die nur cin, cout, cerr und clog berreitstellt.

istream

iterator
mal schauen, ob ich sowas brauchen werde. ich hoffe, es ist nicht nötig.

limits
ok.

list
zu schwach. man braucht wenigstens einfach-verkettete liste als stack und als queue, doppelt verketteten ring und dazu jede sorte nochmal als intrusive version.

locale
wer braucht das?

map
avl-tree mit aufwärtszeigern. wozu sind die aufwärtszeiger gut? und die schnittstelle ist umständlich wenn man speed will und teuer wen man [] schreiben will.

memory
?

(ein paar ausgelassen)

stack
ganz schlimmes ding. man mag stack nicht benutzen. es tut einem weh.

string
copy-on-write ist out. wegen weil wir ganz viel multithreading machen wollen und weil wir nix locken wollen. und weil die allokatoren schneller geworden sind.

typeinfo
schade, daß man zu einem sprachmittel gleichzeitig die klasse exception kaufen muss. das erinnert mich stark an java, wo string-literale von objekt erben.

vector
zu teuer. es fehlt die alternative für statischen speicher, es fehlt reinkonstruieren statt reinkopieren mit push_back.

ist alles nichts schlimmes. aber so alles zusammen nervt's dann doch ein wenig. und ich hab im moment viel zeit. und ich lerne viel dabei. allerdings auf die gefahr hin, daß ich nächstes jahr gar nicht mehr mit normalem c++ arbeiten kann.

Artchi

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

Beispiele? Hier:

http://www.kharchi.de/vcpp2003/dynhelp.png
http://www.kharchi.de/vcpp2003/dynhelp2.png
http://www.kharchi.de/vcpp2003/dynhelp3.png

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

virtuell Realisticer

Artchi schrieb:

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

Beispiele? Hier:

http://www.kharchi.de/vcpp2003/dynhelp.png
http://www.kharchi.de/vcpp2003/dynhelp2.png
http://www.kharchi.de/vcpp2003/dynhelp3.png

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das
Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum
Thema ueber die Sockets in der vhlib zurueckkommen, oder?

mfg
v R

volkard

Artchi schrieb:

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

die ide kennt eine liste von dateinamen, die als C++-Source interpretiert werden sollen. na, klasse. was ein trick. helau!
es ändert nix daran, daß das weglassen der dateinamenerweiterung eine größliche fehlentscheidung war. wieviele jahre wird es dauern, bis sich alle ides angepaßt haben? und dann gibts noch den explorer, woher soll der den dateityp kennen? andere explorer? ja, auch ein ftp-uploader, der anhand der erweiterung den binary-modus setzt oder nicht (also *.pl, *.cgi als ascii und *.jpg als binary). soll der raten?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

wegen solcher sachen benutze ich das VS nicht mehr. mit notapad, einem makefile und ein ganz wenig framework hat man inzwischen mehr spaß, als mit dem VS. als es angefangen hat, daß der focus ins fehlermeldungendfenster geht, statt im source-fenster zu bleiben, isses für mich gestorben. und es wird immer schlechter.

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

kannste mir sagen, weshalb die erwreiterungen abgeschafft wurden? kannste mir einen vernünftigen weg zeigen, wie ein ftp-uploader den dateityp erkennt, wenn auf einmal jeder keine erweiterungen mehr benutzt?
kannst dich ja noch auf den standpunkt stellen, daß würde nur c++ betreffen und für die paar files könne man ne feste liste machen. aber erstens ist das weit gefehlt, weil die compilerbauer mehr files bauen als im standard vorgeschrieben ist und die files machen sie sinnvollerweise ohne erweiterungen. und dann würde die dateityperkennung sogar wissen müssen, welchen compiler in welcher version du drauf hast. nein mehr noch, was ist, wenn jemand mehrere compiler benutzt? und wenn die anderen communitoes mit dem gleichen recht anfangen, ihre erweiterungen fallenzulassen, dann ist aber schluß mit lustig. dem mp3-player ist egal, wie die datei heißt. und mit meinen hard-rock-kumpels spiele ich hier im keller songs mit feinen namen wie iostream oder new. da guckste! und die ide guckt auch, wenn sie ein 12M großes lied aufmachen soll und gerade nachdenkt, welcher schwachmat denn so viel code in eine datei packt. aber die ersten zeichen bis zum eof werden lustig eingefärbt. wenigstens etwas.

wie war nochmal dein argument gegen dateinamenerweiterungen? man soll sie abschaffen, weil es ides gibt, die sie nicht brauchen?

Artchi

Ein Screenshot fehlt noch:

http://www.kharchi.de/vcpp2003/syntax_std.png

volkard

virtuell Realisticer schrieb:

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum Thema ueber die Sockets in der vhlib zurueckkommen, oder?

artchis einwand ist irgendwie on-topic.

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Artchi

wie war nochmal dein argument gegen dateinamenerweiterungen? man soll sie abschaffen, weil es ides gibt, die sie nicht brauchen?

Kannst du das bitte zitieren, wo ich das behauptet habe? Nur bin ich der Meinung, das ich eine IDE benutze, damit mir sowas letztendlich egal ist. Wer natürlich alles handmade machen will, kann das natürlich tun. Nur wird es nichts nützen, wenn man auf das Std-Commitee motzt. Du kannst übrigens eine Stimme beim Commitee kaufen, um mit abzustimmen. Ich finde auch sehr vieles in C++ nicht toll! Aber ich behelfe mir dann, in dem ich mir das passende Werkzeuge besorge um die Nachteile wieder auszubessern. Man muß halt das beste draus machen, wenn man in der C++ nur ein kleines Licht ist und nicht die Macht des Committees hat.

My 2 cent.

Artchi

volkard schrieb:

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Ich persönlich benenne meine Header immer mit hpp und gehe den Weg den Boost geht. Die Groß- und Kleinschreibung richte ich danach, wie sich die Klasse nennt.

virtuell Realisticer

volkard schrieb:

virtuell Realisticer schrieb:

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum Thema ueber die Sockets in der vhlib zurueckkommen, oder?

artchis einwand ist irgendwie on-topic.

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Wenn moeglich socket.h, meinetwegen auch socket.hpp, aber hauptsache klein. Bei Shades
Lib hatte ich unter Unix echt Probleme, da die Dateien GrossUndKlein geschrieben waren,
aber z. B. nur klein includiert. Das macht unter Windows keinen Unterschied, aber
unter Unix wird auch hier zwischen Gross- und Kleinschreibung unterschieden.

Nur socket ist bloed hab keine so tolle IDE wie der vc (kann der auch Dateien ohne
Endung highlighten, die nicht zum Standard gehoeren?).

mfg
v R