Clientsockets aus der vhlib

die vhlib benutzt keine anderen bibliotheken (naja, außer ein wenig winapi und zeugs aus <unistd.h>).

wir die vhlib denn nicht linux portabel?

ich füchte, SSL ohne fremde libs ist ein wenig happig.

damit hast du wohl recht, dachte da an OpenSSL

im moment mache ich den ClientSocket hübscher

könntest dir paar andere socket lib anschauen, dann siehst du was du hübscher machen kannst, falls es deínen vorstellungen entsinnt...

wer baut eigentlich an der vhlib alles mit?

cu

volkard

cplusplus. schrieb:

die vhlib benutzt keine anderen bibliotheken (naja, außer ein wenig winapi und zeugs aus <unistd.h>).

wir die vhlib denn nicht linux portabel?

doch, weitgehend linux-portabel wird sie.
wobei ich unter umständen auch mal ne sinnvolle annahme mache, die mich von einer besonders kranken architektur aussperren könnte.
außerdem fällt mir ein fall ein, wo win und linux zu unterschiedlich waren, um ein gemeinsames verfahren zu wählen. dort werde ich für win eine linux-emulation bauen, also ein paar takte zahlen, um auf beiden seiten mich wie unter linux zu fühlen.

im moment mache ich den ClientSocket hübscher

könntest dir paar andere socket lib anschauen, dann siehst du was du hübscher machen kannst, falls es deínen vorstellungen entsinnt...

schau mal in den dezeitigen code. dann siehste, warum ich nicht abgucken kann.

wer baut eigentlich an der vhlib alles mit?

zur zeit bin ich der einzige regelmäßige mitarbeiter. aber das geht auch nicht anders.

ich denke an folgendes modell mit den rechten und so:
ich habe das urheberrecht. wer mitschreibt, überträgt für eingesendeten code das urheberrecht an mich. im gegenzug verpflichte ich mich, den code für jeden und zu jedem zweck und ohne lizenzgebühren freizugeben.

das einzige, was ich im moment bräuchte, wäre jemand, der hin und wieder ein wenig windows-code linuxifiziert.

virtuell Realisticer

Moin,

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.

Ist das absicht? Diese Informationen werden ja immer wieder benoetigt, gerade
bei einem ServerSocket, der spaeter ja mal accept(en) koennen muss.

mfg
v R

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?