Clientsockets aus der vhlib

volkard

vhlib++ schrieb:

ne vhlib::hash_map wäre noch geil

dann bau sie.

änderungen seit letztem mal: die ganzen lokalen klassen wieder in eigene header getan, es wurde doch zu unübersichtlich.
IPAddress erstmal in ConnectAddress umgenannt, denn der user will IPAddress auch haben, und zwar für ein ding, das 4 bytes kostet und recht schnell ist und kopierbar ist.

ich dachte du bist der experte in sachen hashtable/map.

ich leider nicht

Shade Of Mine

volkard schrieb:

änderungen seit letztem mal: die ganzen lokalen klassen wieder in eigene header getan, es wurde doch zu unübersichtlich.

Richtig geil waere es, wenn du ein CVS/SVN repository machen wuerdest so dass wir alle live miterleben koennen was so passiert dann kann man auch gut sachen vorschlagen und leichter mithelfen

Shade Of Mine schrieb:

volkard schrieb:

änderungen seit letztem mal: die ganzen lokalen klassen wieder in eigene header getan, es wurde doch zu unübersichtlich.

Richtig geil waere es, wenn du ein CVS/SVN repository machen wuerdest so dass wir alle live miterleben koennen was so passiert dann kann man auch gut sachen vorschlagen und leichter mithelfen

dann richte eins ein.

SideWinder

Sollte sich auf SourceForge ohne weiteres erledigen lassen, die Frage ist nur ob das nicht vollkommen overpowered ist. Wie wärs einfach mit einem History-File das online steht *g*

MfG SideWinder

evilissimo

SideWinder schrieb:

Sollte sich auf SourceForge ohne weiteres erledigen lassen, die Frage ist nur ob das nicht vollkommen overpowered ist. Wie wärs einfach mit einem History-File das online steht *g*

MfG SideWinder

ich wäre eher für berlios.de da kann man svn + cvs haben und hat eine höhere Geschwindigkeit

BR

phlox81

Lasst Volkard doch einfach mal werkeln, dann gehts am schnellsten

Ansonsten kann ja jeder der sich dazu berufen fühlt, eine
erweiterung für die lib schreiben, und dann hier vorstellen

wir brauchen auf jeden fall ein vhlib unterforum

hi volkard,
wie wärs mit einem SSL support für vhlib? gibt kaum gute socket libs die SSL spupportn;-( würd mich auch für die SSL implementierung zur verfügung stellen, vielleicht hat kingruedi auch lust...

cu

cplusplus. schrieb:

hi volkard,
wie wärs mit einem SSL support für vhlib? gibt kaum gute socket libs die SSL spupportn;-( würd mich auch für die SSL implementierung zur verfügung stellen, vielleicht hat kingruedi auch lust...

cu

komm mal wieder runter...

volkard

cplusplus. schrieb:

hi volkard,
wie wärs mit einem SSL support für vhlib? gibt kaum gute socket libs die SSL spupportn;-( würd mich auch für die SSL implementierung zur verfügung stellen, vielleicht hat kingruedi auch lust...

meine nächsten ziele führen relativ geradlinig zu einem http-server. für SSL sehe ich in den nächsten jahren keinen bedarf.

die vhlib benutzt keine anderen bibliotheken (naja, außer ein wenig winapi und zeugs aus <unistd.h>). ich füchte, SSL ohne fremde libs ist ein wenig happig.

im moment mache ich den ClientSocket hübscher. und danach muss ich mich vor dem ServerSocket an die Threads machen. da kann mir auch keiner helfen, es ist fast nur überlegen und ausprobieren, was sich für mich "hübsch" anfühlt.

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