4. Problem mit asynchronem UDP-Socket

Problem mit asynchronem UDP-Socket

  • C

    Hi,

    sorry, dass ich es hier reinposte, aber sonst passt es nirgends, denn es ist weder MFC noch WinAPI oder C++-Standard.

    Also, ich erstelle einen Socket, setze ihn asynchron:

    unsigned long lErrorCode = ioctlsocket(m_hSocket, FIONBIO, &lArg);

    Dann wird der Socket noch gebunden (beim Clientsocket ohne Portangabe), ich binde ihn auch beim Client explizit, damit ich sofort empfangen kann ohne erst was senden zu müssen, ja, das macht kein Sinn, aber mein Netzwerkkonzept basiert auf erst empfangen dann senden.

    Mein Problem ist jetzt aber, dass nachdem ich Daten mit sendto gesendet habe, das nächste recvfrom() mit dem Fehlercode 10054 abbricht:

    long lSentBytes = sendto(m_hSocket, reinterpret_cast<const char*>(pBuffer), lSize, 0,
		reinterpret_cast<const SOCKADDR*>(&destination), sizeof(destination));

    unsigned long lBytesRead = recvfrom(m_hSocket, reinterpret_cast<char*>(pBuffer), lSize, 0,
		reinterpret_cast<SOCKADDR*>(sender), addrLen);

    Fehler 10054 ist WSAECONNRESET also Connection Reset by Peer. Nur, wie kann das überhaupt bei dem verbindungslosen (!) UDP-Protokoll passieren. Wie gesagt, passiert es nur, wenn ich sendto() aufgerufen habe, recvfrom() kann ich ganz normal beliebig oft aufrufen.

    ChrisM

    PS: Wenn ich den recvfrom()-Teil rausnehme und ihn quasi in einer Endlosschleife senden lasse, schlägt sendto() nach einigen Malen mit Fehler 10004 fehl. Ist wenigstens das normal?

    0
  • R

    warum ist das kein WinAPI Problem? Die Problematik liegt doch in der WinAPI Implementierung. Ich verschieb dich mal

    0
  • C

    Hi,

    naja, das Problem tritt ja nicht nur unter Windows auf... 🙂

    ChrisM

    0
  • C

    Hi,

    *push*

    ChrisM

    0
  • C

    Hi,

    sorry, ich bin's schon wieder.

    Habe das Problem jetzt eingegrenzt; könnte es sein, dass recvfrom() immer 10054 (WSAECONNRESET) zurückliefert, wenn auf ein vorheriges sendto() der Zielhost ein ICMP-Packet "Port unreachable" (d.h. dort kein UDP-Socket an den Port gebunden ist) zurückliefert.

    Im Momemt deutet nämlich alles darauf hin und auf mehreren Seiten bei Google les' ich es so, die Frage ist nur, wie kann ich das verhindern? Nehmen wir an, auf einem Client stürzt der Client ab, kann also kein Quit-Signal an den Server schicken. Es kann ja nicht sein, dass dann der Server zwangsläufig den Socket verliert.

    ChrisM

    0
  • W

    ChrisM schrieb:

    könnte es sein, dass recvfrom() immer 10054 (WSAECONNRESET) zurückliefert, wenn auf ein vorheriges sendto() der Zielhost ein ICMP-Packet "Port unreachable" (d.h. dort kein UDP-Socket an den Port gebunden ist) zurückliefert?

    MSDN schrieb:

    On a UDP-datagram socket this error indicates a previous send operation resulted in an ICMP Port Unreachable message.

    Gut übersetzt! 😉

    0
  • C

    Hi,

    MSDN? Bei mir (Offlineversion, die bei .net 2003 war) hab ich schon so ziemlich alles zu UDP und den sendto()-/recvfrom()-Funktionen gelesen, aber nichts gefunden. 😞

    Aber ich denke, man muss den einen recvfrom()-Aufruf dann einfach ignorieren (ggf. Logeintrag erstellen) und der nächste geht wieder normal. Kann es aber noch nicht bestätigen, weil die Netzwerkengine jetzt mal wieder gar nicht will, nachdem ich das Queue-System erweitert habe und ich ab morgen bis zum nächsten Samstag nicht mehr zum Coden komme (bin weg).

    ChrisM

    0
  • H

    Link zur MSDN

    0
  • C

    Hi,

    thx, nur komisch, dass das in der Offlineversion nicht auffindbar ist... naja, egal, ich krieg' das jetzt hin. 🙄

    ChrisM

    0
  • H

    Hast du das neueste Platform-SDK installiert?

    Normalerweise decken sich die Aussagen des neuesten PSDK (Februar 2003) und der Online-Version (ebenfalls Februar 2003)...

    0
  • C

    Hi,

    ne, ich hab noch die Version, die bei MSVC .net 2003 dabei war.

    ChrisM

    0
Anmelden zum Antworten