Skip to content

SocketServer.DatagramRequestHandler with empty response #45276

Description

@alzheimer
mannequin
BPO 1767511
Nosy @giampaolo, @tiran, @vadmium, @desbma
Files
  • DatagramServer.diff: patch & test for proposed new behaviour
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = None
    created_at = <Date 2007-08-04.09:21:27.000>
    labels = ['type-bug', '3.8', '3.9', '3.10', 'library', 'docs']
    title = 'SocketServer.DatagramRequestHandler with empty response'
    updated_at = <Date 2020-11-04.11:42:06.528>
    user = 'https://bugs.python.org/alzheimer'

    bugs.python.org fields:

    activity = <Date 2020-11-04.11:42:06.528>
    actor = 'iritkatriel'
    assignee = 'docs@python'
    closed = False
    closed_date = None
    closer = None
    components = ['Documentation', 'Library (Lib)']
    creation = <Date 2007-08-04.09:21:27.000>
    creator = 'alzheimer'
    dependencies = []
    files = ['9271']
    hgrepos = []
    issue_num = 1767511
    keywords = []
    message_count = 5.0
    messages = ['32586', '61578', '61579', '61582', '259958']
    nosy_count = 7.0
    nosy_names = ['giampaolo.rodola', 'christian.heimes', 'alzheimer', 'bpb', 'docs@python', 'martin.panter', 'desbma']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = 'needs patch'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue1767511'
    versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

    Activity

    1. alzheimer commented on Aug 4, 2007

      alzheimermannequin
      MannequinAuthor

      I seem to have misunderstood SocketServer completely, maybe someone can tell me if I was using the wrong thing after all.

      I wanted to implement an UDP protocol in Python. For sending and receiving UDP packets, I chose SocketServer.UDPSocketServer along with the DatagramRequestHandler.

      It is probably implied, but did not become clear to me just by reading the documentation, that apparently a server is meant to send back a packet for every packet it receives, no matter what. Which in turn means that you can't have servers talk to other servers, because they'd be sending packets back and forth endlessly then.

      At least, that's what the DatagramRequestHandler is doing. It issues a socket.sendto in its finish() routine. Took me a while to find out where all the empty packets where coming from...

      Does it make sense at all for an UDP server to do this? Sure, it works for simple protocols that do nothing but query/answer. But it's really useless for anything else.

      The documentation could be more verbose on this behaviour, in any case.

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Aug 4, 2007
    3. bpb commented on Jan 23, 2008

      bpbmannequin
      Mannequin

      I've just bumped into this issue. In my opinion the finish() method
      should only do anything if wfile is not empty, i.e:

      temp = self.wfile.getvalue()
      if temp:
          self.socket.sendto(temp, self.client_address)
    4. tiran commented on Jan 23, 2008

      @tiran
      Member

      Can you provide a working patch with a unit test and doc updates?

    5. added
      type-bugAn unexpected behavior, bug, or error
      on Jan 23, 2008
    6. bpb commented on Jan 23, 2008

      bpbmannequin
      Mannequin

      Main issue here (as I see it) is that StreamRequestHandler and
      DatagramRequestHandler should behave in the same way. This is not the
      case in Python 2.5.1 for the case where the handle method does not
      respond to the request socket (e.g. in my case it is forwarding data to
      a different socket).

      While handler methods in StreamRequestHandler need not send any data
      back to the request socket, in DatagramRequestHandlers an attempt will
      be made to send data whether any is available or not. This causes a
      socket hang (for several minutes) on Windows with a '10040 Message too
      long' error.

      By only sending data back to the request if the handler has written to
      wfile, this is avoided, giving the twin fixes of avoiding a nasty
      socket error and providing compatibilty with StreamRequestHandler
      behaviour.

      Test has been updated to add tests of handlers which do not respond to
      the request; this causes a hang in Python2.5.1 stock (not sure how to
      avoid this and cleanly fail), test passes with changed SocketServer.

      p.s. this is my first patch submission to anything, so go easy :-)

    7. vadmium commented on Feb 9, 2016

      @vadmium
      Member

      Sorry that nobody has responded to your patch in almost a decade. :( Unfortunately in the meantime the test file seems to have been completely rewritten.

      For the original problem, I think it would be better if we just documented that this is the way it works. Sending an empty response message seems like a plausible way to acknowledge handling of a request. This parallels the stream handler only shutting down the connection when the request handler has finished. Changing this could break compatibility.

      Ben: if you’re still interested, can you explain what the problem is on Windows? My experiments with Wine on Linux suggest that it can send empty UDP responses fine. Is Windows able to send and receive zero-length UDP messages with plain sockets? Perhaps this should be a separate bug.

    8. changed the title [-]SocketServer.DatagramRequestHandler[/-] [+]SocketServer.DatagramRequestHandler with empty response[/+] on Feb 9, 2016
    9. transferred this issue fromon Apr 10, 2022
    10. added
      pendingThe issue will be closed if no feedback is provided
      and removed on Sep 21, 2025
    11. devdanzin commented on Sep 21, 2025

      @devdanzin
      Member

      This one is waiting for feedback for 9 years, so unless someone proposes keeping it open (and provides tests, updated patch, etc.), it will soon be closed.

    12. soreavis commented on Jul 19, 2026

      @soreavis
      Contributor

      Still reproduces at tip (3.16): DatagramRequestHandler.finish() calls sendto() unconditionally, so a handler that writes nothing to wfile still sends a zero-byte datagram back. But that matches vadmium's 2016 read — he called the empty datagram a plausible way to acknowledge a request, and thought making the send conditional could break compatibility. Nothing new has arrived since (nobody answered vadmium's 2016 Windows question, and that hang was never reproduced separately). Looks closable as not planned; the one actionable leftover would be the short doc note vadmium suggested in 2016 — a line in Doc/library/socketserver.rst saying DatagramRequestHandler always sends a reply datagram, empty if the handler wrote nothing. I can send that if it's wanted.

      Quick check at current main (6df4993)
      import socket, socketserver, sys, threading
      print(sys.version)
      
      class NoReplyHandler(socketserver.DatagramRequestHandler):
          def handle(self):
              pass  # write nothing to wfile
      
      srv = socketserver.UDPServer(("127.0.0.1", 0), NoReplyHandler)
      threading.Thread(target=srv.handle_request, daemon=True).start()
      c = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
      c.settimeout(5)
      c.sendto(b"ping", srv.server_address)
      data, addr = c.recvfrom(1024)
      print("reply received anyway: len =", len(data), "data =", data)
      srv.server_close()
      3.16.0a0 (remotes/upstream/HEAD:6df4993bb64, Jul 19 2026, 20:24:53) [Clang 21.0.0 (clang-2100.1.1.101)]
      reply received anyway: len = 0 data = b''
      
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      docsDocumentation in the Doc dirpendingThe issue will be closed if no feedback is providedstdlibStandard Library Python modules in the Lib/ directorytopic-socketRelated to the socket, socketserver and selectors modulestype-bugAn unexpected behavior, bug, or error

      Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions