Winsock "Recv übergehen"?



  • Hi leute,
    ich habe ein programm geschriebn mit einem main-loop und in diesem main-loop wartet er auf tastendrücke und soll immer gucken ob ein packet empfangen wurde.

    nun mein problem ist halt das er bei jedem recv stehen bleibt und auf nen packet wartet, nur kommen halt nicht immer packets.

    kann ich das recv irgentwie so machn das es nur kurz nach nem packet prüft und dann weiter geht?

    also auch wenn keins gekommen is weiter geht?

    Lukas



  • ja nonblocking sockets zb



  • und wie gehn die? ... ^^



  • ioctlsocket



  • non-blocking = schlechte Idee -> CPU-Bombe

    select() = gute Idee -> sockets auf Lesbarkeit prüfen

    Etwas genauer:

    Mit select() kannst Du Deine sockets, die Du in einem FD_SET anlegst, dahingehend prüfen, dass Du weißt, ob Daten gesendet wurden, sodass Du recv() einsetzen kannst.
    Somit setzt Du recv() nur ein, wenn lesbare Daten vorhanden sind und recv() kann nach dem Lesen sofort wieder zurückkehren.

    Das schöne an select() ist, dass select() selber blockiert bis sich auf einem Deiner sockets etwas tut.

    Da Du allerdings zusätzlich Tastenanschläge prüfen möchtest, kannst Du select() einen timeval-Pointer mitgeben, d.h. einen Timeout für select() festlegen. Dieses Timeout bestimmt, nach welcher Zeit select() zurückkehren soll, falls sich auf Deinen sockets nichts getan hat.

    Danach fragst Du dann Deine Tastaturanschläge ab. Fertig.

    Meine ICQ: 262-189-411

    (Hab mich grad selbst in das Thema eingearbeitet und helfe daher gerne, wenn das unklar ist ;))

    lg Max



  • non-blocking sockets + select = gute Idee



  • a123, das solltest Du Dir nochmal anschauen.

    Entweder man kann mit select() umgehen oder man kann es nicht.
    Kann man es, so ist non-blocking absolut überflüssig.

    Ich denke Du kannst es nicht.

    Mit non-blocking kannst Du Deine Rechner gern vergewaltigen, aber lass andere davon verschont.

    Danke.

    lg Max



  • Spätestens wenn du auch was senden willst wird klar das man non-blocking Sockets benötigt. select sagt dir nicht wieviel du senden kannst ohne das send() blockiert. WSAAsyncSelect und WSAEventSelect setzen den Socket auch in den Non-blocking Modus.

    select + non blocking sockets != 100% CPU Auslastung



  • In welchem Fall sollte send() blockieren? send() blockiert nicht!

    lg Max



  • MaDsTyLe mach dich ned zum affen. meine antwort war kurz und korrekt, deine lang und lame. also lass gut sein du nachtfalke.



  • MaDsTyLe schrieb:

    In welchem Fall sollte send() blockieren? send() blockiert nicht!

    mach dich ned zum affen



  • Scheiß Satzdiebstahl



  • Informatik-Student und so lasch ...

    Registrier Dich mal lieber und zeig was Du drauf hast, anstatt hier solch unproduktive und leichtfertige Beiträge abzuliefern.

    Kritik muss man abkönnen, auch wenn ein 16jähriger spricht.

    lg Max



  • MaDsTyLe schrieb:

    a123, das solltest Du Dir nochmal anschauen.

    Entweder man kann mit select() umgehen oder man kann es nicht.
    Kann man es, so ist non-blocking absolut überflüssig.

    Ich denke Du kannst es nicht.

    Und du kannst es schon garnicht. select() mit blocking Sockets hat einige (IMO unlösbare) Probleme. z.B. heisst "select jetzt" nicht dass du gleich noch senden kannst - der Zustand kann sich jederzeit ändern. Und wie schon gesagt wurde kannst du nicht wissen wieviel du senden kannst. Und ja, send() blockiert.

    select() mit non-blocking Sockets ist OK. Non-blocking Sockets *ohne* select() sind ein Problem, aber davon hat hier auch niemand was geschrieben.

    Auch gut ist asynchroner IO, wie z.B. mit IO Completion Ports (Windows), oder ähnlichen Mechanismen unter *NIX (siehe Boost.ASIO).

    Mit non-blocking kannst Du Deine Rechner gern vergewaltigen, aber lass andere davon verschont.

    Danke.

    Sei mal nicht so patzig, vor allem wenn du keinen Plan hast.



  • Hi hustbaer,

    ich weiß nicht wo Dein Problem beim Senden an defekte Sockets liegt. Wenn ich an einen fehlerhaften Socket sende, so bekomme ich einen Fehler zurück. Von einem Block kann aber keine Rede sein.

    D.h. sollte ein Socket mit select() als writeable bestimmt werden und es beim Aufruf von send() nicht mehr sein, kann man den Fehler abfangen und alles ist Wölkchen.

    Unter Windows z.B. kann man das dann natürlich mit WSAGetLastError genauer untersuchen. Die möglichen Fehler sind hier gelistet:
    http://www.c-plusplus.net/forum/viewtopic-var-p-is-1517176.html

    WSAETIMEDOUT
    The connection has been dropped, because of a network failure or because the system on the other end went down without notice.

    Nur als Beispiel.

    Ich hab das Gefühl, das Ganze geht am Thema vorbei und hilft im Grunde dem Thread-Starter nicht mehr, wenn wir hier unsere eigenen Diskussionen starten.

    lg Max



  • send(..) blockiert in bestimmten Fällen:
    http://msdn.microsoft.com/en-us/library/ms740149.aspx

    Simon



  • MaDsTyLe warum redest du von defekten Sockets? Davon war nie die Rede.



  • Weil er ein 16 jähriger Mongo ist.



  • @ ????????:

    Dabei drehte es sich um den von hustbaer angesprochenen writeable-Status.
    Wobei Du schon Recht hast, ein Socket muss nicht defekt sein um nicht empfangen zu können. Reine Kontextinterpretationsfrage <- schönes Wort.

    @ Inf.Student:

    "mach dich ned zum affen"

    lg Max



  • Scheiß Satzdiebstahl


Anmelden zum Antworten