nonblocking sockets melden wsaewoudblock
-
ich hab mir nen socket angelegt, der ist nodelay mit nem wsaevent auf error | recv | close er ist also ist der socket nonblocking, schön und gut ich habe mich verbunden, und sende meine daten mit send, returnwert stimmt mit zu sendenden bytes überein blabla...
wenn ich jedoch das handle abfrage und recv mache kommt permanent return socketerror und auf getlasterror() kommt wsaewouldblock trotz das daten anliegen (ich kontrolliere das mit etheral)
ich bin steh jetzt irgendwie aufm schlauch, hab ich eventuell ne option vergessen oder was falsch gesetzt ?der socket ist auch nicht mehrfach offen und wird auch vorher nicht zurückgesetzt, es ist derselbe socket den aich auch zum senden verwende
thx im voraus
-
Dass ich mich direkt mit den Win32-API sockets befasst habe ist lange her, ich glaube aber, dass das normal ist. Näheres findest du bestimmt hier.
http://search.msdn.microsoft.com/search/Default.aspx?query=wsaewouldblock&brand=msdn&locale=en-us&refinement=00&lang=en-us
-
das ist definitiv nicht normal und da hab cih auch schon gesucht, ich hab echt n problem. by the way windows XP wird verwendet
-
wsaewouldblock beim recv() heißt doch einfach nur, dass im Moment nicht genug Daten im Empfangsbuffer liegen und der Aufruf blockierend sein müsste, um keinen Fehler zurückzuliefern.
http://msdn2.microsoft.com/en-us/library/ms740121.aspxEtheral kann nicht wissen, was Windows mit den Sockets macht.
-
ja schon aber es sind DEFINITIV (geprüft mit etheral)genug daten da, das isses was mich so fertig macht
-
ok problem gelöst, des rätsels lösung hab ich zwar nicht gefunden aber cih habe einfach das setsockopt(nodelay) VOR das connect gestellt. jetzt klappt es bis auf ein paar signalausreisser ganz gut
-
Naja das hört sich wieder mal nach einer äußerst schrägen Lösung an. Leute, nehmt euch einfach mal die 5 Minuten Zeit und lest die paar Seiten auf der MSDN durch. Dann müsst ihr nicht irgendwelche komischen Behelfslösungen zusammenbasteln, die euch dann später nur wieder Probleme machen.
-
warte doch einfach mit select/WSASelect bis Daten anliegen und schau mit ioctlsocket wie viele Daten da sind und hohle diese dann einfach ab
-
schau mit ioctlsocket wie viele Daten da sind
das hört sich wieder mal nach einer äußerst schrägen Lösung an
-
wenn man das benutzen einer API als schräg bezeichnet, dann ja
FIONREAD
Use to determine the amount of data pending in the network's input buffer that can be read from socket s. The argp parameter points to an unsigned long value in which ioctlsocket stores the result. FIONREAD returns the amount of data that can be read in a single call to the recv function, which may not be the same as the total amount of data queued on the socket. If s is message oriented (for example, type SOCK_DGRAM), FIONREAD still returns the amount of pending data in the network buffer, however, the amount that can actually be read in a single call to the recv function is limited to the data size written in the send or sendto function call.