Clientsockets aus der vhlib

volkard

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.

und jetzt bin ich erstmal ganz traurig , weil ich doch ne klasse String bauen muß, bevor ich eine http-request lesen kann. das ist traurig, schade und gemein. ich bin gar nicht so weit für die strings. aber naja, vieleicht hat's auch was gutes, wenn ich frühzeitig die sachen wie dateinamen zu Strings statt char const* mache.

warum?

ich meine, wie kommst du jetzt auf einmal darauf das du ne String-Klasse brauchst??

volkard

strings schrieb:

ich meine, wie kommst du jetzt auf einmal darauf das du ne String-Klasse brauchst??

um die http-request zeilenweise lesen zu können.
der browser schickt sowas wie

GET / HTTP/1.1\r\n
Host: 192.168.1.1\r\n
Connection: close\r\n

und am einfachsten isses, wenn ich das zeilenweise auslese und dann in ruhe die zeilen analysiere. um die zeilen zwischenzuspeichern, bietet sich eine string-klasse an.

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