sockets -- basic udp client

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • 7stud

    sockets -- basic udp client

    My question pertains to this example:

    #!/usr/bin/env python

    import socket, sys, time

    host = sys.argv[1]
    textport = sys.argv[2]

    s = socket.socket(s ocket.AF_INET, socket.SOCK_DGR AM)
    try:
    port = int(textport)
    except ValueError:
    # That didn't work. Look it up instread.
    port = socket.getservb yname(textport, 'udp')

    s.connect((host , port))
    print "Enter data to transmit: "
    data = sys.stdin.readl ine().strip()
    s.sendall(data)
    s.shutdown(1)
    print "Looking for replies; press Ctrl-C or Ctrl-Break to stop."
    while 1:
    buf = s.recv(2048)
    if not len(buf):
    break
    print "Received: %s" % buf


    As far as I can tell, the if statement:

    if not len(buf):
    break

    does nothing. Either recv() is going to read some data or it's going
    to block. My understanding is that udp sockets do not have a
    connection, so the server can't close the connection--hich would cause
    a blank string to be sent to the client.

    So, as far as I can tell, the only way that code would make sense is
    if the server were programmed to send a blank string to the client
    after it sent data to the client. Is that correct?
  • Gabriel Genellina

    #2
    Re: sockets -- basic udp client

    En Fri, 15 Feb 2008 20:24:19 -0200, 7stud <bbxx789_05ss@y ahoo.com>
    escribió:
    My question pertains to this example:
    >
    #!/usr/bin/env python
    >
    import socket, sys, time
    >
    host = sys.argv[1]
    textport = sys.argv[2]
    >
    s = socket.socket(s ocket.AF_INET, socket.SOCK_DGR AM)
    try:
    port = int(textport)
    except ValueError:
    # That didn't work. Look it up instread.
    port = socket.getservb yname(textport, 'udp')
    >
    s.connect((host , port))
    print "Enter data to transmit: "
    data = sys.stdin.readl ine().strip()
    s.sendall(data)
    s.shutdown(1)
    print "Looking for replies; press Ctrl-C or Ctrl-Break to stop."
    while 1:
    buf = s.recv(2048)
    if not len(buf):
    break
    print "Received: %s" % buf
    >
    >
    As far as I can tell, the if statement:
    >
    if not len(buf):
    break
    >
    does nothing. Either recv() is going to read some data or it's going
    to block. My understanding is that udp sockets do not have a
    connection, so the server can't close the connection--hich would cause
    a blank string to be sent to the client.
    >
    So, as far as I can tell, the only way that code would make sense is
    if the server were programmed to send a blank string to the client
    after it sent data to the client. Is that correct?
    That example is plain wrong; looks like some TCP code but with SOCK_STREAM
    blindy replaced with SOCK_DGRAM. connect, sendall and recv are not used
    for UDP; sendto and recvfrom are used instead. There are some examples in
    the Demo python directory.

    --
    Gabriel Genellina

    Comment

    • 7stud

      #3
      Re: sockets -- basic udp client

      On Feb 15, 6:48 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.a r>
      wrote:
      En Fri, 15 Feb 2008 20:24:19 -0200, 7stud <bbxx789_0...@y ahoo.com 
      escribió:
      >
      >
      >
      My question pertains to this example:
      >
      #!/usr/bin/env python
      >
      import socket, sys, time
      >
      host = sys.argv[1]
      textport = sys.argv[2]
      >
      s = socket.socket(s ocket.AF_INET, socket.SOCK_DGR AM)
      try:
          port = int(textport)
      except ValueError:
          # That didn't work.  Look it up instread.
          port = socket.getservb yname(textport, 'udp')
      >
      s.connect((host , port))
      print "Enter data to transmit: "
      data = sys.stdin.readl ine().strip()
      s.sendall(data)
      s.shutdown(1)
      print "Looking for replies; press Ctrl-C or Ctrl-Break to stop."
      while 1:
          buf = s.recv(2048)
          if not len(buf):
              break
          print "Received: %s" % buf
      >
      As far as I can tell, the if statement:
      >
      if not len(buf):
         break
      >
      does nothing.  Either recv() is going to read some data or it's going
      to block.   My understanding is that udp sockets do not have a
      connection, so the server can't close the connection--hich would cause
      a blank string to be sent to the client.
      >
      So, as far as I can tell, the only way that code would make sense is
      if the server were programmed to send a blank string to the client
      after it sent data to the client.  Is that correct?
      >
      That example is plain wrong; looks like some TCP code but with SOCK_STREAM 
      blindy replaced with SOCK_DGRAM. connect, sendall and recv are not used  
      for UDP; sendto and recvfrom are used instead. There are some examples in  
      the Demo python directory.
      >
      --
      Gabriel Genellina
      On Feb 15, 6:48 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.a r>
      wrote:
      En Fri, 15 Feb 2008 20:24:19 -0200, 7stud <bbxx789_0...@y ahoo.com 
      escribió:
      >
      >
      >
      My question pertains to this example:
      >
      #!/usr/bin/env python
      >
      import socket, sys, time
      >
      host = sys.argv[1]
      textport = sys.argv[2]
      >
      s = socket.socket(s ocket.AF_INET, socket.SOCK_DGR AM)
      try:
          port = int(textport)
      except ValueError:
          # That didn't work.  Look it up instread.
          port = socket.getservb yname(textport, 'udp')
      >
      s.connect((host , port))
      print "Enter data to transmit: "
      data = sys.stdin.readl ine().strip()
      s.sendall(data)
      s.shutdown(1)
      print "Looking for replies; press Ctrl-C or Ctrl-Break to stop."
      while 1:
          buf = s.recv(2048)
          if not len(buf):
              break
          print "Received: %s" % buf
      >
      As far as I can tell, the if statement:
      >
      if not len(buf):
         break
      >
      does nothing.  Either recv() is going to read some data or it's going
      to block.   My understanding is that udp sockets do not have a
      connection, so the server can't close the connection--which would cause
      a blank string to be sent to the client.
      >
      So, as far as I can tell, the only way that code would make sense is
      if the server were programmed to send a blank string to the client
      after it sent data to the client.  Is that correct?
      >
      That example is plain wrong; looks like some TCP code but with SOCK_STREAM 
      blindy replaced with SOCK_DGRAM. connect, sendall and recv are not used  
      for UDP; sendto and recvfrom are used instead. There are some examples in  
      the Demo python directory.
      >

      Yes, I agree it's a poor example--it's from 'Foundations of Python
      Network Programming'--but it does 'work'. It also doesn't appear to
      be a tcp client that was converted too directly into a udp client
      because the previously presented tcp examples are different.

      Here is the example above converted to a more straightforward udp
      client that isolates the part I am asking about:

      import socket, sys

      host = 'localhost' #sys.argv[1]
      port = 3300
      s = socket.socket(s ocket.AF_INET, socket.SOCK_DGR AM)


      data = 'hello world'
      num_sent = 0
      while num_sent < len(data):
      num_sent += s.sendto(data, (host, port))


      print "Looking for replies; press Ctrl-C or Ctrl-Break to stop."
      while 1:
      buf = s.recv(2048)

      #Will the following if statement do anything?
      if not len(buf):
      break

      print "Received from server: %s" % buf



      Another question I have pertains to the docs here:

      getservbyname(s ervicename[, protocolname])
      Translate an Internet service name and protocol name to a port number
      for that service. The optional protocol name, if given, should be
      'tcp' or 'udp', otherwise any protocol will match.


      What does a 'servicename' look like?

      Comment

      • 7stud

        #4
        Re: sockets -- basic udp client

        On Feb 16, 6:32 am, "Gabriel Genellina" <gagsl-...@yahoo.com.a r>
        wrote:
        That example is plain wrong; looks like some TCP code but with  
        SOCK_STREAM  
        blindy replaced with SOCK_DGRAM. connect, sendall and recv are not used 
        for UDP; sendto and recvfrom are used instead. There are some examples  
        in  
        the Demo python directory.
        >
        Yes, I agree it's a poor example--it's from 'Foundations of Python
        Network Programming'--but it does 'work'.  It also doesn't appear to
        be a tcp client that was converted too directly into a udp client
        because the previously presented tcp examples are different.
        >
        Ok, you *can* use those functions with datagrams too, but it's confusing  
        (at least for the very first UDP example!)
        >
        Yes, I agree. The book is well written, but the introductory examples
        and a lack of explanation of the finer details is a disaster.

        Another question I have pertains to the docs here:
        >
        getservbyname(s ervicename[, protocolname])
        Translate an Internet service name and protocol name to a port number
        for that service. The optional protocol name, if given, should be
        'tcp' or 'udp', otherwise any protocol will match.
        >
        What does a 'servicename' look like?
        >
        pyimport socket
        pysocket.getser vbyname("http")
        80
        pysocket.getser vbyname("smtp")
        25
        >
        On Linux the mapping ports<->services is in /etc/services; on Windows see  
        %windir%\system 32\drivers\etc\ services
        >
        --
        Gabriel Genellina
        Thanks.

        Comment

        • rluse1@gmail.com

          #5
          Re: sockets -- basic udp client

          If you don't care about the address of the sender, e.g. you are not
          going to send anything back, is there an advantage to using recv()?
          Or, as a matter of course should you always use recvfrom() with udp
          sockets?


          I don't know of a reason why you couldn't use recvfrom() all the time,
          and that is what I do. However, I also don't see a reason why you
          should
          not use recv() if you don't care who the message comes from.
          Historically,
          though, the ultimate authority on this kind of stuff is

          Richard Stevens and his Unix and TCP/IP books

          I recommend these books if you want to get into network programming.

          Cheers,
          Bob

          Comment

          • Paul Rubin

            #6
            Re: sockets -- basic udp client

            "rluse1@gmail.c om" <rluse1@gmail.c omwrites:
            Historically, though, the ultimate authority on this kind of stuff is
            Richard Stevens and his Unix and TCP/IP books
            >
            I recommend these books if you want to get into network programming.
            I keep wanting to get that book, but it gets older and older. Have
            things really not changed since it was written?

            Comment

            • Steve Holden

              #7
              Re: sockets -- basic udp client

              Paul Rubin wrote:
              "rluse1@gmail.c om" <rluse1@gmail.c omwrites:
              >Historically , though, the ultimate authority on this kind of stuff is
              >Richard Stevens and his Unix and TCP/IP books
              >>
              >I recommend these books if you want to get into network programming.
              >
              I keep wanting to get that book, but it gets older and older. Have
              things really not changed since it was written?
              TCP is much like a funicular railway: it's been around long enough that
              the basic engineering principles are known and the basic bugs have been
              ironed out. Stevens is still an excellent reference.

              regards
              Steve
              --
              Steve Holden +1 571 484 6266 +1 800 494 3119
              Holden Web LLC http://www.holdenweb.com/

              Comment

              Working...