Clientsockets aus der vhlib

[volkard]

socker schrieb:

Meiner Meinung ist schon beides gleichzeitig erwünscht.

meiner meinung nach nicht. irgendwann wird der große schalter umgelegt, und man benutzt ab da nurnoch IPv6.

[volkard]

virtuell Realisticer schrieb:

jo. bei mir ändert es sich langsam zu Socket (ehemals ClientSocket) und sowas wie (Listener?).

Listener, jemand der auf irgend einem Port horscht? Aber das macht unser
ServerSocket ja schon bzw. zumindest wird er entsprechendes ueber ein accept()
anbieten

ja. welche namen möchte ich als anwendungsprogrammierer denn sehen? normalerweise sage ich nur "socket" und meine das, was im code gerade unter CLientSocket steht.
als programmierer des clients wäre mir "Socket" ein feiner name für das, was im moment ClientSocket heisst. wie sieht es mit dem programmierer des servers aus? naja, der code für nen listener, der nen threadpool dahinter hat und sowas ist ja eh immer gleich. letztendlich muss der serverprogrammierer sowas wie ne Worker-klasse bauen. ein ding, das vorgesehen ist, um in einem thread abzulaufen und einen job zu tun (evtl auch viele jobs in ner schleife, aber egal). diese sorte von server-programmierern würde auch am liebsten "Socket" sagen. mir scheint sogar, "Socket" ist der gute name für den den halben teil einer connection, also eine ip-adresse und einen port. daß das listen-zeugs auch mit socket implemetiert wird, scheint mir eher ein technischer hack zu sein.

mir gefällt die idee, den ehemaligen ClientSocket nun einfach Socket zu nennen. wie soll ich den ehemaligen ServerSocket nennen?

Z. b. fuer bind oder connect. Ich ging jetzt einfach davon aus, dass z. B. ein
ServerSocket einen Socket benutzt und nicht davon erbt.

er erbt auch nicht, er hat einen, um nicht private erblichkeit zu verwenden.

und was macht conqueue?

listen erwartet als zweiten Parameter die Anzahl einkommender Verbindung, die
in eine Warteschlange gestellt werden. Ist sie voll, werden weitere Verbindungen nicht mehr akzeptiert, bis wieder Platz ist. Daher dieser Parameter.

ok. sowas rüste ich gerne nach. weil manchmal kommt es doch vor, daß man sowas auch weglassen kann, weil man in 5 jahren nicht den komischen fall hat. wie lange hat es gedauert, bis du bemerkt hast, daß dein compiler das schlüsselwort switch gar nicht kennt?

[socker]

volkard schrieb:

socker schrieb:

Meiner Meinung ist schon beides gleichzeitig erwünscht.

<ironie>meiner meinung nach nicht. irgendwann wird der große schalter umgelegt, und man benutzt ab da nurnoch IPv6.</ironie>

[virtuell Realisticer]

volkard schrieb:

virtuell Realisticer schrieb:

jo. bei mir ändert es sich langsam zu Socket (ehemals ClientSocket) und sowas wie (Listener?).

Listener, jemand der auf irgend einem Port horscht? Aber das macht unser
ServerSocket ja schon bzw. zumindest wird er entsprechendes ueber ein accept()
anbieten

ja. welche namen möchte ich als anwendungsprogrammierer denn sehen? normalerweise sage ich nur "socket" und meine das, was im code gerade unter CLientSocket steht.
als programmierer des clients wäre mir "Socket" ein feiner name für das, was im moment ClientSocket heisst. wie sieht es mit dem programmierer des servers aus? naja, der code für nen listener, der nen threadpool dahinter hat und sowas ist ja eh immer gleich. letztendlich muss der serverprogrammierer sowas wie ne Worker-klasse bauen. ein ding, das vorgesehen ist, um in einem thread abzulaufen und einen job zu tun (evtl auch viele jobs in ner schleife, aber egal). diese sorte von server-programmierern würde auch am liebsten "Socket" sagen. mir scheint sogar, "Socket" ist der gute name für den den halben teil einer connection, also eine ip-adresse und einen port. daß das listen-zeugs auch mit socket implemetiert wird, scheint mir eher ein technischer hack zu sein.

mir gefällt die idee, den ehemaligen ClientSocket nun einfach Socket zu nennen. wie soll ich den ehemaligen ServerSocket nennen?

Ja, gute Frage. Vielleicht einfach so belassen? Oder ein Socket, der beides
kann? Oder ist das dann doch zuviel Overhead?

Ich bin im Designen so unwahrscheilich schlecht.

Z. b. fuer bind oder connect. Ich ging jetzt einfach davon aus, dass z. B. ein
ServerSocket einen Socket benutzt und nicht davon erbt.

er erbt auch nicht, er hat einen, um nicht private erblichkeit zu verwenden.

und was macht conqueue?

listen erwartet als zweiten Parameter die Anzahl einkommender Verbindung, die
in eine Warteschlange gestellt werden. Ist sie voll, werden weitere Verbindungen nicht mehr akzeptiert, bis wieder Platz ist. Daher dieser Parameter.

ok. sowas rüste ich gerne nach. weil manchmal kommt es doch vor, daß man sowas auch weglassen kann, weil man in 5 jahren nicht den komischen fall hat.

Nur steht das ja gar nicht zur Diskussion, da listen nunmal einen solchen
Parameter erwartet. Man kann natuerlich sagen, 5 reicht, da oft 5 als
Standardwert genutzt wird. Allerdings hat der Benutzer dieser Klasse dann
darauf keinen Einfluss mehr.

wie lange hat es gedauert, bis du bemerkt hast, daß dein compiler das schlüsselwort switch gar nicht kennt?

Das habe ich nicht verstanden, bitte um Erklaerung.

socker schrieb:

volkard schrieb:

socker schrieb:

Meiner Meinung ist schon beides gleichzeitig erwünscht.

<ironie>meiner meinung nach nicht. irgendwann wird der große schalter umgelegt, und man benutzt ab da nurnoch IPv6.</ironie>

Wieso sollte es Ironie sein?

mfg
v R

[volkard]

virtuell Realisticer schrieb:

wie lange hat es gedauert, bis du bemerkt hast, daß dein compiler das schlüsselwort switch gar nicht kennt?

Das habe ich nicht verstanden, bitte um Erklaerung.

kann dein compiler switch? woher weißte das? du hast dich sicherlich seizt dem letzten compilerupdate das wort switch gar nicht benutzt. ich meinte das als beispiel für was sehr seltenes.

[virtuell Realisticer]

volkard schrieb:

virtuell Realisticer schrieb:

wie lange hat es gedauert, bis du bemerkt hast, daß dein compiler das schlüsselwort switch gar nicht kennt?

Das habe ich nicht verstanden, bitte um Erklaerung.

kann dein compiler switch? woher weißte das? du hast dich sicherlich seizt dem letzten compilerupdate das wort switch gar nicht benutzt. ich meinte das als beispiel für was sehr seltenes.

Ok, jetzt hab ichs

mfg
v R

[volkard]

virtuell Realisticer schrieb:

Ich bin im Designen so unwahrscheilich schlecht.

unfug.
alle sind von natur aus im designen unwahrscheinlich schlecht.

das ist genau wie mit dem gedichte-schreiben. wobei ich mal eher die klassischen gedichte meine, die sich reimen, die einem nahe gehen und dennoch nicht unanständig sind. manch ein modernes gedicht ist ja offensichtlich hingekotzt und die geschickte wird auch entsprechend richten. den dichtern fließt auch nicht einfach ein meisterwerk nach dem anderen aus der feder, sondern es ist echt arbeit. unendliches gefummele und ausprobieren. den guten dichter macht zunächst nicht aus, daß er ein glückliches händchen hat, obwohl das erstens sehr hilfreich ist und zweitens sich sich auch mit jahrzehntelangem training auch einigermaßen ausbildet, sondern der qualitätsanspruch des dichters. das schlagwort der "brotlosen kunst" drängt sich auf. für auftragsprojekte kannste einfach nicht sehr breit suchen und nachher was haben, von dem du echt überzeugt bist (außer der auftraggeber wünscht genau das, aber ist sehr selten).

und die leute, die von sich sagen, daß sie gut designen können, sind sehr gut vergleichbar mit den leuten, die auch sagen, daß sie gute Moderatoren wären. wer um mod-rechte bettelt, ist mit sicherheit kein guter mod. und wer drum bettelt, designen zu dürfen, der kann mit sicherheit nicht coden. und ich kenne ach, so viele, die in irgendwelche projektleiterstellungen schlüpfen wollen, weil sie ihr info-diplom haben aber nicht coden können (nach eigenen messungen können 3/4 von denen nichtmal doppelten dreisatz!).

dich kenne ich jetzt recht lange aus dem forum und wenn ich in der lage wäre, dich oder einen wildfremden einzustellen, dannn würde ich dich nehmen, egal, welche diplomnote der andere hätte. auch, wenn wir mal unterschiedlicher meinung sind, so ist doch immer wieder klar, daß du die meinungen nicht nur "fühlst", sondern "erdenkst". kannst sie außerdem vertreten und bisher übersehene gegenargumente einbauen.

sag lieber sowas wie

virtuell Realisticer schrieb:

Ich bin im Designen zwar deutlich überdurchschnittlich, aber zu schlecht für meine eigenen Maßstäbe.

[neueVersion.rar]

kannst du vielleicht immer mal wieder ne neue version hochladen?

[volkard]

neueVersion.rar schrieb:

kannst du vielleicht immer mal wieder ne neue version hochladen?

jo. immer unter dem gleichen namen vhlib.rar
hab gerade den aktuellen stand hochgeladen. compiliert zwar nicht, aber man sieht die weiteren absichten.

neu:
Range.h
klasse zum speichern von begin-end-paaren

String.h
klasse String (so simpel wie möglich)
und StringLiteral (naja, es hat mich übermannt)

und der Reader hat getLine() gelernt, damit ich bald die zeilen einer http-request lesen darf.

[virtuell Realisticer]

Sicher, dass es der gleiche Link ist? In der Datei befindet sich bei mir keine
Range.h oder String.h.

mfg
v R

[hier]

?

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.

[v6]

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

[80]

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

ist es eigentlich irgendwo dokumentiert welche protokolle getaddrinfo kennt?