Subclassing socket

[groups.20.thebriguy]

socket objects have a little quirk. If you try to receive 0 bytes on a
blocking socket, they block. That is, if I call recv(0), it blocks
(until some data arrives).

I think that's wrong, but I don't want to argue that. I would like to
create a subclass of socket that fixes the problem. Ideally, something
like:

class new_socket(socket):
def recv( self, bufsize, flags=0 ):
if bufsize == 0:
return ""
else:
return socket.recv( bufsize, flags )

They only problem is, sockets return socket objects via the accept
call. And the socket returned is of type socket, of course, not
new_socket, as I would like. I could override accept() to return a
new_socket, but I don't know how to convert the old socket to a new
socket. That is, I'd like to add a method to the class above something
like:

def accept( self ):
conn, addr = socket.accept()
<convert conn, which is type socket to type new_socket>
return ( conn, addr )

Does anyone have any suggestions on how to do the above?

 

[Pelmen]

imho:
class new_socket(socket):
def __init__(self, family=AF_INET, type=SOCK_STREAM, proto=0,
_sock=None)
socket.__init__(self, family=AF_INET, type=SOCK_STREAM, proto=0,
_sock=None)

def accept( self ):
conn, addr = socket.accept()
return ( new_socket(_sock=conn), addr )

but i think your problem have a more simple way then inheritance

 

[Maksim Kasimov]

you have to agregate socket and the object must have "fileno" method,
thats gives a possibility to use instanses of your class with "select.select" function


class mySocket:

def __init__(self, ...):
self.__socket = None
...


def fileno(self):
return self.__socket.fileno()


def connect(self, __host, __port):
try:
self.close()
self.__socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.__socket.connect((__host, __port))
...


def close(self):
try:
if self.__socket is not None:
self.__socket.close()
finally:
self.__socket = None

...

 

[groups.20.thebriguy]

More simple way? What's that?

 

[Steve Holden]

socket objects have a little quirk. If you try to receive 0 bytes on a
blocking socket, they block. That is, if I call recv(0), it blocks
(until some data arrives).

Well, arguably you should just try to stop receiving zero bytes. Why on
earth is your application doing this?

I think that's wrong, but I don't want to argue that. I would like to
create a subclass of socket that fixes the problem. Ideally, something
like:

class new_socket(socket):
def recv( self, bufsize, flags=0 ):
if bufsize == 0:
return ""
else:
return socket.recv( bufsize, flags )

That would indeed work, were it not for the complications you are about
to relate.

They only problem is, sockets return socket objects via the accept
call. And the socket returned is of type socket, of course, not
new_socket, as I would like. I could override accept() to return a
new_socket, but I don't know how to convert the old socket to a new
socket. That is, I'd like to add a method to the class above something
like:

def accept( self ):
conn, addr = socket.accept()
<convert conn, which is type socket to type new_socket>
return ( conn, addr )

Does anyone have any suggestions on how to do the above?

You could use the "delegation" pattern - return an object that contains
a reference to the socket returned by accept(), and have that object
implement recv() as you outline above, and __getattr__() so that any
methods your socket *doesn't* implement are instead called on the socket
returned by accept().

There's a whole page of stuff at

http://aspn.activestate.com/ASPN/search?query=delegation&x=0&y=0&type=ASPN

but the best read will probably be

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52295

In that article Alex talks about how old-style classes can't inherit
from basic Python types. This is out of date now for most types, but his
exposition of the principles of delegation remains a beacon of clarity.

regards
Steve

 

[groups.20.thebriguy]

Steve,

To your question of why you'd ever receive value:

This is very common in any network programming. If you send a packet
of data that has a header and payload, and the header contains the
length (N) of the payload, then at some point you have to receive N
bytes. If N is zero, then you receive 0 bytes. Of course, you CAN
test for N == 0, that's obvious - but why would you if the underlying
layers worked correctly? Its just extra code to handle an special case.

 

[groups.20.thebriguy]

Correction to my last post:

It should say:

"To your question of why you'd ever recv(0):"

 

[Bryan Olson]

To your question of why you'd ever [recv(0)].

This is very common in any network programming. If you send a packet
of data that has a header and payload, and the header contains the
length (N) of the payload, then at some point you have to receive N
bytes. If N is zero, then you receive 0 bytes. Of course, you CAN
test for N == 0, that's obvious - but why would you if the underlying
layers worked correctly? Its just extra code to handle an special case.

We need "extra code" around recv to ensure we get exactly
N bytes; 'recv(N)' can return less. The most straightforward
code I know to read exactly N bytes never passes zero to
recv (untested):


def recvall(sock, size):
""" Read and return exactly 'size' bytes from socket 'sock'.
Kind of the other side of sock.sendall.
"""
parts = []
while size > 0:
data = sock.recv(size)
if not data:
raise SomeException("Socket closed early.")
size -= len(data)
parts.append(data)
return ''.join(parts)

 

[groups.20.thebriguy]

I don't think this is true in all cases - for example, if the protocol
is UDP, and the packet size is less than the MTU size. Although, I
could be wrong - I've always thought that to be the case.

I knew someone would have your response, that's why I earlier said I
didn't want to argue that.

But thanks for your comments.

 

[Paul Rubin]

I would like to
create a subclass of socket that fixes the problem.

The socket module is in a messy state right now and subclassing
sockets doesn't work for implementation-specific reasons besides the
issue you described. Take a look at socket.py to see the situation.

See also:

http://groups.google.com/group/comp...read/thread/76d27388b0d286fa/c9849013e37c995b

 

[Steve Holden]

Steve,

To your question of why you'd ever receive value:

This is very common in any network programming. If you send a packet
of data that has a header and payload, and the header contains the
length (N) of the payload, then at some point you have to receive N
bytes. If N is zero, then you receive 0 bytes. Of course, you CAN
test for N == 0, that's obvious - but why would you if the underlying
layers worked correctly? Its just extra code to handle an special case.

I understand all that, but you are presumably also aware that a
zero-length result from recv() indicates that the other party to a TCP
connection has closed their end of the socket?

Given that information, it's hard to know why you would ever really want
to recv(0), since the presumably empty return string would effectively
prohibit you form detecting that condition.

So I'd suggest a test for a requirement of zero bytes, with a
corresponding skip of the recv() call in those cases, at least for TCP.

regards
Steve