[C++]Blokkerende socket

[Verwijderd]

Ellowkes,
Onderstaande functie leest 1 lijn invoer van een socket in. Het probleem is dat hij blockt totdat er daadwerkelijk input is. Is het mogelijk om een time-out in te stellen?

C++:

bool SocketReadLine(SOCKET s) {
    vector<char> dataVector;
    char buffer;
    char *pChar;
    int result;
    printf("Receiving... ");
    bool bReceiving=true;
    int err;

    while (bReceiving)
    {
        if ( (result=recv(s,&buffer,1,0))!=SOCKET_ERROR )
        {
            switch (buffer)
            {
                case '\n': // end of input
                    pChar = new char[dataVector.size() + 1];
                    memset(pChar, 0, dataVector.size() + 1);
                    for (int f = 0; f<dataVector.size(); f++)
                        pChar[f] = dataVector[f];
                    printf("%s\n",pChar);
                    bReceiving=false;
                    break;
                default:  // regular input
                    dataVector.push_back(buffer);
                    break;
            }
        } else { // socket error
            err = WSAGetLastError();        // Get a more detailed error
            printf("\nError: %d\n",err);
            return false;
        }
    }
    return true;
}

[ Voor 22% gewijzigd door Verwijderd op 27-02-2003 19:50 ]

[whoami]

Met een thread werken.

[Verwijderd]

whoami schreef op 27 February 2003 @ 19:32:
Met een thread werken.

Mag ik vragen hoe dat moet en wat dat doet? Kben een n00b in socket programming ,vandaar. En een duidelijke n00b-documentatie is er niet te vinden (iig niet over time-outs of threads)

[madwizard]

select gebruiken? result vergelijken met WSAECONNRESET of andere winsock error codes gaat niet lukken trouwens. Als recv SOCKET_ERROR returnt kan je de error code opvragen met WSAGetLastError.

[Exirion]

Je kunt sockets ook non-blocking maken met setsockopt().

Nadeel is wel dat je leesloop dan heel veel wordt uitgevoerd en je veel cpu-load genereert. Select is de mooiste optie, en kan ook meerdere handles bewaken.

[ Voor 59% gewijzigd door Exirion op 27-02-2003 19:49 ]

[Verwijderd]

Exirion schreef op 27 February 2003 @ 19:47:
Je kunt sockets ook non-blocking maken met setsockopt().

Nadeel is wel dat je leesloop dan heel veel wordt uitgevoerd en je veel cpu-load genereert. Select is de mooiste optie, en kan ook meerdere handles bewaken.

k, beide bedankt, kheb die functie trouwens een beetje aangepast nu.
[n00b_mode]Hoe implementeer ik die select?[/n00b_mode]

[Exirion]

Verwijderd schreef op 27 February 2003 @ 19:51:
[n00b_mode]Hoe implementeer ik die select?[/n00b_mode]

Zoek voorbeelden met google

Vanmiddag heb ik zelf aan een server zitten coden dus kan zo copy/pasten, maar zoek gewoon de documentatie van select op en zoek naar voorbeelden van hoe het te gebruiken.

[Verwijderd]

kheb wat gevonden:
http://tangentsoft.net/ws...sics/threaded-server.html

bedankt voor jullie hulp!!!

[.oisyn]

kom op, dit staat echt allemaal uitvoerig beschreven in de MSDN

overigens is het misschien wel interessant om met asynchrone (WSAAsyncSelect, dan krijgt je windowproc een message als er iets aan de hand is) of overlapped (WSARecv/WSASend, dan wordt er een event gezet of een routine aangeroepen als er data verstuurd of ontvangen is) sockets te werken

[curry684]

.oisyn schreef op 28 February 2003 @ 12:15:
kom op, dit staat echt allemaal uitvoerig beschreven in de MSDN

overigens is het misschien wel interessant om met asynchrone (WSAAsyncSelect, dan krijgt je windowproc een message als er iets aan de hand is) of overlapped (WSARecv/WSASend, dan wordt er een event gezet of een routine aangeroepen als er data verstuurd of ontvangen is) sockets te werken

Overlapped en async zijn redelijk rot om te implementeren. Niet zozeer onmogelijk maar je bent met een simpele threadpool dubbel zo snel klaar... select is nog simpeler afhankelijk van wat je aan het bouwen bent.

[rig0r]

select() gebruiken, eventueel in combinatie met non blocking sockets.

[whoami]

rig0r schreef op 28 February 2003 @ 13:08:
select() gebruiken, eventueel in combinatie met non blocking sockets.

Als je de draad eerst gelezen had, dan had je gezien dat men dit al lang voorgesteld heeft....

[Verwijderd]

Na wat opzoekwerk (zie laatste post) vond ik artikels over select() en threading. Select code is véél groter (de code om te inialiseren iig) en meer bedoeld voor servers met een groot aantal client connecties. Voor m'n multiplayer game lijkt threading een betere keuze. De voorbeeldcode op de webpagina van m'n vorige post is ideaal hiervoor.

[rig0r]

whoami schreef op 28 February 2003 @ 13:33:

[...]


Als je de draad eerst gelezen had, dan had je gezien dat men dit al lang voorgesteld heeft....

Nee, de combinatie van non blocking en select() was nog niet voorgesteld. Als je select() voor je non blocking read of write zet voorkom je dat et ding onnodig gaat lopen pollen en 100% cpu op eet.

[Exirion]

rig0r schreef op 01 March 2003 @ 11:56:
Nee, de combinatie van non blocking en select() was nog niet voorgesteld. Als je select() voor je non blocking read of write zet voorkom je dat et ding onnodig gaat lopen pollen en 100% cpu op eet.

Dan snap jij blijkbaar weinig van select, want select blockt nou juist totdat er iets binnenkomt op een socket. Nonblocking sockets in combinatie met select zijn dus onzinnig

[.oisyn]

rig0r, Exirion: blijkbaar kennen jullie beide de functie select () niet. Het heeft namelijk een timeout parameter: als je die niet meegeeft (NULL dus) dan blockt ie tot er wat beschikbaar is, en anders wordt er gewacht tot de timeout verstreken is

Het al dan niet blocking zijn van de sockets heeft er helemaal niets mee te maken

[rig0r]

.oisyn schreef op 02 March 2003 @ 16:47:
rig0r, Exirion: blijkbaar kennen jullie beide de functie select () niet. Het heeft namelijk een timeout parameter: als je die niet meegeeft (NULL dus) dan blockt ie tot er wat beschikbaar is, en anders wordt er gewacht tot de timeout verstreken is

Het al dan niet blocking zijn van de sockets heeft er helemaal niets mee te maken

Zucht. In een eerdere post werd als nadeel van non blocking sockets vermeld dat je cpu tijd verspilt als je je non blocking read in een loop hebt staan. Mijn punt is dat als je select() (JA met een timeout ja, DUH) voor je read zet, je dat probleem verhelpt.

[rig0r]

Exirion schreef op 01 March 2003 @ 11:57:
[...]

Dan snap jij blijkbaar weinig van select, want select blockt nou juist totdat er iets binnenkomt op een socket. Nonblocking sockets in combinatie met select zijn dus onzinnig

Nee, dus niet. Jij bouwt liever een applicatie die loopt door een non blocking read() en 100% cpu eet dan een applicatie die in de loop voorafgaand aan de read() eerst (d.m.v. select() evt. met timeout) kijkt of er wat te readen valt. Het eerste geval heet polling, en dient vermeden te worden.

[Exirion]

.oisyn schreef op 02 March 2003 @ 16:47:
rig0r, Exirion: blijkbaar kennen jullie beide de functie select () niet. Het heeft namelijk een timeout parameter: als je die niet meegeeft (NULL dus) dan blockt ie tot er wat beschikbaar is, en anders wordt er gewacht tot de timeout verstreken is

Het al dan niet blocking zijn van de sockets heeft er helemaal niets mee te maken

Ik gebruik 'm vaak genoeg dus weet echt wel hoe het werkt. Bovendien, wat jij zegt zei ik toch ook? Als je geen timeout opgeeft dan blockt ie totdat er wat op de socket verschijnt. Of je de socket nou blocking of non-blocking maakt is niet relevant, en dus is de combinatie van select met een non-blocking socket zinloos. Dat is wat ik bedoelde, en ook met wat jij zegt blijft dat overeind Het enige verschil is dat jij de timeout vermeldt, maar dat is hier verder niet aan de orde.

[Exirion]

rig0r schreef op 02 March 2003 @ 17:09:
Nee, dus niet. Jij bouwt liever een applicatie die loopt door een non blocking read() en 100% cpu eet dan een applicatie die in de loop voorafgaand aan de read() eerst (d.m.v. select() evt. met timeout) kijkt of er wat te readen valt. Het eerste geval heet polling, en dient vermeden te worden.

Ehh? Volgens mij moet je beter lezen. De topicstarter vraagt hoe ie non-blocking sockets kan hebben en ik vertel hem hoe dat kan. Ik vertel er wel bij dat het ivm CPU-load beter is om select te gebruiken. En select blockt toch wel, of je nou een blocking socket of een non-blocking socket gebruikt. Ik pleit er dus niet voor om te pollen, integendeel.

[MisterData]

Als je socket programming n00b bent, dan kun je beter een makkelijkere API gebruiken, zoals JNetlib van Nullsoft (www.nullsoft.com) of zelfs wxWindows (www.wxwindows.org)

[rig0r]

Exirion schreef op 02 March 2003 @ 17:21:
[...]

Ehh? Volgens mij moet je beter lezen. De topicstarter vraagt hoe ie non-blocking sockets kan hebben en ik vertel hem hoe dat kan. Ik vertel er wel bij dat het ivm CPU-load beter is om select te gebruiken. En select blockt toch wel, of je nou een blocking socket of een non-blocking socket gebruikt. Ik pleit er dus niet voor om te pollen, integendeel.

Waarom zeg je dan

"Nonblocking sockets in combinatie met select zijn dus onzinnig :)"

?

Of bedoel je blocking sockets in combinatie met select zijn onzinnig, want dat is idd waar.

[Exirion]

rig0r schreef op 02 March 2003 @ 19:52:
Of bedoel je blocking sockets in combinatie met select zijn onzinnig, want dat is idd waar.

Leg mij dan maar eens uit waarom Ben erg benieuwd.

[.oisyn]

rig0r, Exirion: zo te zien heb ik jullie beide posts verkeerd gelezen was er blijkbaar niet helemaal bij met mijn hoofd

[curry684]

rig0r schreef op 02 maart 2003 @ 19:52:
Of bedoel je blocking sockets in combinatie met select zijn onzinnig, want dat is idd waar.

Wat een nonsens. D'r wordt hier leuk gehamerd op de kernelmode-wait features van select, maar je kijkt over de selecting features van select heen.

Stel ik heb 30 clients in blocking mode aan mijn IRC-servertje hangen. Ik select op een set van die 30 sockets en de serversocket. En zodra select terugvalt krijg ik netjes te horen dat ik van sockets 3, 8 en 23 data moet lezen, en dat er een nieuwe connectie is naar de server socket. Hierdoor kan ik op het gewenste moment de correcte data uitlezen, of bijvoorbeeld een threadje lanceren dat met de blocking socket een langdurige filetransfer aangaat of zo.

[Exirion]

curry684 schreef op 03 March 2003 @ 12:33:
En zodra select terugvalt krijg ik netjes te horen dat ik van sockets 3, 8 en 23 data moet lezen, en dat er een nieuwe connectie is naar de server socket. Hierdoor kan ik op het gewenste moment de correcte data uitlezen, of bijvoorbeeld een threadje lanceren dat met de blocking socket een langdurige filetransfer aangaat of zo.

Exact, en als select met een timeout terugkomt dan lees je gewoon niks. Omdat je alleen leest wanneer select zegt dat er iets te lezen valt, maakt het geen donder uit of je blocking of non-blocking sockets gebruikt. Ik hoopte eigenlijk dat hij nog op mijn vraag om toelichting op zijn bewering zou reageren, maar helaas