Clientsockets aus der vhlib

[volkard]

socker schrieb:

Warum beschränkt ihr die Socket auf IPv4 und IPv6?
Und dann kann man die auch nicht gleichzeitig in einem Programm haben.

ipv4 und ipv6 sind aktuell. wenn man mehr haben mag, isses ja schnell eingebaut.
man kann nicht gleichzeitig v4 und v6 haben, weil man das nicht gleichzeitig haben will, soweit ich recht informiert bin.

VR schrieb:

Aber was mir gerade durch den Kopf schwirt:
Es geht um Socket und ServerSocket (kommt noch ein ClientSocket? Ist in meiner
Ueberlegung mit drinne). Socket kapselt die Informationen ueber den Socket.

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

Soweit ist das ja klar. Dazu gehoert, imho, auch sockaddr dazu. Habs bei mir lokal einfach mal mit reingebaut.

kann ich einfach nicht nacvollziehen. wozu brauchste das nachher?

Und ServerSocket nutzt Socket. Allerdings wird im Socket direkt auch schon ein
connect gemacht, warum? Wenn man Aufteilung in ClientSocket und ServerSocket
macht, dann macht der ClientSocket ein connect und der ServerSocket lediglich
ein bind und listen.

Also das connect aus Socket raus und rein in den ClientSocket.

jup.

Der mag dann entweder eine Elementfunktion 'connect' haben, die
ein Socket nimmt oder aber direkt connecten. Ne, das als Elementfunktion ist
ja doch irgendwie doof, lieber direkt connecten, weil warum sollte jemand sonst
einen ClientSocket erstellen?

jo.

Obwohl, sollte ein connect man schieflaufen und der Herr Programmierer aber den
connect mehrmals versuchen wollen, weil es koennte ja sein, dass ein Host nur
mal kurz down ist, dann waere eine simple 'connect'-Elementfunktion ja doch
angebracht, oder?

nö. der Herr Programmierer soll dann halt mehrmals... nö, am ende verlangste noch, daß ich bool liefere, ob's geklappt hat. so nicht!

Und der ServerSocket? Der nutzt auch brav Socket. Aber er braucht nicht connect, sonder bind und listen. Aber bind und listen koennen getrost im CTor aufgerufen werden. Fuer bind haben wir alle Infos im Socket. Fuer listen braeuchten wir noch angaben vom Benutzer. Aber im Moment haben wir nur en Standard-CTor.

also haben wir jetzt ServerSocket und ClientSocket und beide erben von Socket. Socket macht ::socket und ::closesocket. nur dazu ist Socket überhaut eingeführt worden.
tatsächlich benutzt der server für seine connections aber die gleichen clientsockets wie der client. also so mit op>> und op<< und ::shutdown() am ende. deswegen mag ich die biester nicht mehr clientsocket nennen. ich versuche es mal mit Socket.

ServerSocket servSock(Socket("0.0.0.0", 514), conqueue);

Oder wolln wir das nicht?

den code verstehe ich gar nicht. gar überhaupt nicht. warum sollte ich einem Socket, der nur ::socket und ::closesocket kann, adressen mitgeben? die werden doch NUR zum bind benötigt. also dürfen die auch NUR dem ctor von ServerSocket übergeben werden. und was macht conqueue?

er code wird vermutlich eher mal

ServerSocket s("0.0.0.0","514");

werden.
im moment nebst

ClientSocket ServerSocket::accept();

[virtuell Realisticer]

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

kann ich einfach nicht nacvollziehen. wozu brauchste das nachher?

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

Ok, irgendwie bloed von mir, davon auszugehen...

nö. der Herr Programmierer soll dann halt mehrmals... nö, am ende verlangste noch, daß ich bool liefere, ob's geklappt hat. so nicht!

Ok, weg mit der Elementfunktion-Idee. Willst ne Exception schmeissen, wenn
connect nicht funktioniert?

also haben wir jetzt ServerSocket und ClientSocket und beide erben von Socket.

Davon war ich gar nicht ausgegangen. s. o. Frag mich nicht warum, aber so ist
es natuerlich schluessiger.

Socket macht ::socket und ::closesocket. nur dazu ist Socket überhaut eingeführt worden.
tatsächlich benutzt der server für seine connections aber die gleichen clientsockets wie der client. also so mit op>> und op<< und ::shutdown() am ende. deswegen mag ich die biester nicht mehr clientsocket nennen. ich versuche es mal mit Socket.

Ok.

ServerSocket servSock(Socket("0.0.0.0", 514), conqueue);

Oder wolln wir das nicht?

den code verstehe ich gar nicht. gar überhaupt nicht. warum sollte ich einem Socket, der nur ::socket und ::closesocket kann, adressen mitgeben? die werden doch NUR zum bind benötigt. also dürfen die auch NUR dem ctor von ServerSocket übergeben werden.

Ja richtig. Wie gesagt, bin da von was anderem ausgegangen. Wie du es
beschrieben hast, macht es mehr Sinn.

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.

er code wird vermutlich eher mal

ServerSocket s("0.0.0.0","514");

werden.
im moment nebst

ClientSocket ServerSocket::accept();

Sieht gut aus.

mfg
v R

[edit]
hab leider meinen beitrag versaut, weil ich auf editieren statt zitieren ging, sry
[/edit]

[socker]

Meiner Meinung ist schon beides gleichzeitig erwünscht.

Hier findeste Beispiel-Code für Server und Client der beides gleichzeitig unterstürzt: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/appendix_b_ip_version_agnostic_source_code_2.asp

[socker]

den code:

#if(IP_Version == 4)
    socketHandle=socket(AF_INET, SOCK_STREAM, 0);
#elif(IP_Version == 6)
    socketHandle=socket(AF_INET6, SOCK_STREAM, 0);
#endif

sollte man besser machen. ist zu viel gleich.

[virtuell Realisticer]

Ok, weg mit der Elementfunktion-Idee. Willst ne Exception schmeissen, wenn
connect nicht funktioniert?

Haette ich mal besser in den Code geschaut...man bin ich bloed :). Hat sich
natuerlich erledigt.

mfg
v R

[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.