[Python-bugs-list] [ python-Bugs-211710 ] socket.send() can do partial writes on some systems.

noreply@sourceforge.net noreply@sourceforge.net
Sun, 21 Oct 2001 18:02:18 -0700


Bugs item #211710, was opened at 2000-08-11 13:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: scott cotton (scottc)
Assigned to: Jeremy Hylton (jhylton)
Summary: socket.send() can do partial writes on some systems.

Initial Comment:
0811 15:57 chronis:~% uname -a
FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000     root@chronis.pobox.com:/usr/src/sys/compile/MYBSD  i386
0811 15:57 chronis:~% 


0811 15:57 chronis:~% cat scratch/sendtstsrv.py     
import socket         
                      
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind("chronis.pobox.com", 8010) 

while 1:
    s.listen(1)
    conn, addr = s.accept()
    print "connected from", addr
    while 1:
        data = conn.recv(1024)
        if not data: break
    print "done"
    conn.close()

0811 15:58 chronis:~% python scratch/sendtstsrv.py &
[2] 76562

0811 15:58 chronis:~% cat scratch/sendtst.py 
#!/usr/bin/env python

s = "0" * 10000000



import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect("chronis.pobox.com", 8010)
sent = sock.send(s)
if sent != len(s):
    print "sent %d/%d chars" % (sent, len(s))
else:
    print "sent all chars"

0811 15:58 chronis:~% python !$
python scratch/sendtst.py
connected from ('208.210.124.49', 1258)
sent 17520/10000000 chars
done
0811 15:58 chronis:~%            


NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a
partial write, though of those systems, it only seems
to reproducibly do partial writes under FreeBSD4.0 Stable.

Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """
A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77).  Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354).

scott

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-21 18:02

Message:
Logged In: YES 
user_id=6380

Please go slowly here.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2001-10-21 00:46

Message:
Logged In: YES 
user_id=29957

On second (or is this third?) thoughts, patching
socket.py to make it wrap the _socketmodule send
code is an alternative approach that may be safer. 

Pity about the _fileobject, tho - it needs considerably
more help.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2001-10-21 00:07

Message:
Logged In: YES 
user_id=29957

The two approaches would seem to be:

  patch the socketmodule to make sure send() actually
  sends all the bytes.
or
  patch the offending std library calls.

The latter preserves the std unix semantics, but possibly
violates the principle of Least Suprise.

For 2.1.2, I'm patching the std library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-19 05:20

Message:
Logged In: YES 
user_id=6380

Reopened. You have a point. (I think we closed it becase we
couldn't reproduce it. Our fault for not having access to
FreeBSD. :-)

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-10-18 23:43

Message:
Logged In: YES 
user_id=6405

This problem is only seen on FreeBSD, it seems. Not even 
OSX, the BSD derivative, has this problem. However, my 
FreeBSD (4.3-RELEASE) socket(2) man page states:

     If no messages space is available at the socket to 
hold the message to be
     transmitted, then send() normally blocks, unless the 
socket has been
     placed in non-blocking I/O mode.  The select(2) call 
may be used to de-
     termine when it is possible to send more data.

Linux (2.4.7) has a similar message:

   When  the message does not fit into the send buffer of 
the
   socket, send normally blocks, unless the socket  has  
been
   placed  in non-blocking I/O mode.  In non-blocking mode 
it
   would return EAGAIN in this case.  The select(2) call  
may
   be  used  to  determine  when  it is possible to send 
more
   data.

So "normally" is being interpreted loosly by FreeBSD in 
this case, it seems.

A solution might be to have socket.send() try to send all 
the data. At a minimum, the standard library should be 
fixed so it works on FreeBSD.

>From the Lib directory of 2.1.1:
[richard@ike /usr/local/src/Python-2.1.1]% grep -r 
'\.send(' Lib
Lib/ftplib.py:        self.sock.send(line)
Lib/ftplib.py:        self.sock.send(line, MSG_OOB)
Lib/ftplib.py:            conn.send(buf)
Lib/ftplib.py:            conn.send(buf)
Lib/gopherlib.py:    s.send(selector + CRLF)
Lib/httplib.py:            self.sock.send(str)
Lib/httplib.py:            self.send(str)
Lib/httplib.py:            self.send(str)
Lib/httplib.py:        self.send(str)
Lib/httplib.py:        self.send('\r\n')
Lib/httplib.py:            self.send(body)
Lib/imaplib.py:            self.sock.send('%s%s' % (data, 
CRLF))
Lib/imaplib.py:                self.sock.send(literal)
Lib/imaplib.py:                self.sock.send(CRLF)
Lib/nntplib.py:        self.sock.send(line)
Lib/poplib.py:        self.sock.send('%s%s' % (line, CRLF))
Lib/smtplib.py:                    sendptr = sendptr + 
self.sock.send(str[sendptr:])
Lib/smtplib.py:        self.send(str)
Lib/smtplib.py:            self.send(q)
Lib/socket.py:            self._sock.send(self._wbuf)
Lib/telnetlib.py:        self.sock.send(buffer)
Lib/telnetlib.py:                    self.sock.send(IAC + 
WONT + opt)
Lib/telnetlib.py:                    self.sock.send(IAC + 
DONT + opt)
Lib/urllib.py:            h.send(data)
Lib/urllib.py:                h.send(data)
Lib/urllib2.py:            h.send(data)
Lib/webbrowser.py:        s.send(action)
Lib/test/test_asynchat.py:            n = conn.send(buffer)
Lib/test/test_socket.py:                conn.send(data)
Lib/test/test_socket.py:            s.send(msg)
Lib/test/test_socketserver.py:    s.send(teststring)


Note that smtplib handles send()'s return, where nothing 
else does. Note also that the above grep does not include 
our patch.




----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-10-18 23:04

Message:
Logged In: YES 
user_id=6405

We have patched httplib.HTTPConnection.send() so it does 
the following:

   sent = 0
   while sent < len(str):
       sent = sent + self.sock.send(str[sent:])

Could this be the default behaviour in the socket module 
perhaps?



----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-10-18 22:57

Message:
Logged In: YES 
user_id=6405

Why is this bug closed? The standard library uses send() 
in a number of places - we've just run up against it in 
httplib. Again, on FreeBSD, we're seeing that send() is 
only sending a part of the data we want it to.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-15 11:50

Message:
scott-- Is there a bug here?  It seems clear that the send system call is not required to send all the bytes you asked it to send.  It returns the number of bytes it did send.  If you want to make sure all your data is sent, you can wrap send in a while loop that calls send until all the data is consumed.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:01

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470