Clientsockets aus der vhlib

@strings: Volkard will die STL in seiner Bibliothek nicht benutzen. Nur windows.h und auf Linux halt das äquivalent. Deshalb darf er nicht std::string benutzen.

virtuell Realisticer

volkard schrieb:

virtuell Realisticer schrieb:

du speicherst dir in deinem Socketcode die Socketinformationen bzw. ich sollte besser sagen die 'Zielinformationen' (sprich sockaddr_in) nicht ab. Das ist der Grund, warum du z. B. in den ServerSocket den bind-Aufruf nicht durchfuehren kannst, da hier diese Informationen benoetigt werden.

auf dem treffen sind wir nicht ganz fertig geworden. aktuell ist (aus MSDN kopiert) (socket ist attribut vom typ Socket mit ::socket() im ctor und ::closesocket() im dtor):
ListeningSocket(){
        sockaddr_in service;
        service.sin_family=AF_INET;
        service.sin_addr.s_addr=inet_addr("127.0.0.1");
        service.sin_port=htons(80);
        SOCKCHECK(bind(socket,(SOCKADDR*)&service,sizeof(service))!=SOCKET_ERROR);
//        SOCKCHECK(listen(socket,SOMAXCONN)!=SOCKET_ERROR);
        SOCKCHECK(listen(socket,16)!=SOCKET_ERROR);
    }
    void accept(){
        SOCKET s=::accept(socket,NULL,NULL);
        SYSCHECK(s!=SOCKET(SOCKET_ERROR));
        cout<<"accepted"<<endl;
    }
und das scheint erstmal zu gehen.

Ja gehen tut das hier sicher. Aber hier hast du fuer bind natuerlich auch
die entsprechenden Informationen.

Aber ok, die lib ist ja noch gar nicht fertig :).

Ist mir nur so aufgefallen

mfg
v R

virtuell Realisticer

Was ich auch nicht verstehe:

Warum nicht in ServerSocket Socket nutzen? Das man nicht immer

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

schreiben muessen ist doch ein Grund, warum man Socket implementiert hat.

Ich hab das bei mir lokal mal ein bissle geaendert und spiele mal en bissle damit
rum. Hab auch mal sockaddr* in Socket mit aufgenommen.

mfg
v R

evilissimo

vhlib-experte schrieb:

@strings: Volkard will die STL in seiner Bibliothek nicht benutzen. Nur windows.h und auf Linux halt das äquivalent. Deshalb darf er nicht std::string benutzen.

Falsch er will es nicht

Warum beschränkt ihr die Socket auf IPv4 und IPv6?

Und dann kann man die auch nicht gleichzeitig in einem Programm haben.

virtuell Realisticer

socker schrieb:

Warum beschränkt ihr die Socket auf IPv4 und IPv6?

Und dann kann man die auch nicht gleichzeitig in einem Programm haben.

Ok, aber das kann schnell geaendert werden. Noch ist es nicht so komplex.

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. Soweit
ist das ja klar. Dazu gehoert, imho, auch sockaddr dazu. Habs bei mir lokal
einfach mal mit reingebaut.

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

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?

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.

Man koennte diesem natuerlich auch einen Socket-Parameter mitgeben. Brauchen
wir eh, wir wollen ja z. B. sowas schreiben wollen:

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

Oder wolln wir das nicht?

Sind nur mal so Gedanken von mir.

mfg
v R

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]

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

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?

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.

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.