By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,842 Members | 2,154 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,842 IT Pros & Developers. It's quick & easy.

Subclassing socket

P: n/a
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?

Dec 21 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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

Dec 21 '05 #2

P: n/a

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

...
gr*****************@spamgourmet.com wrote:
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?

--
Best regards,
Maksim Kasimov
mailto: ma************@gmail.com
Dec 21 '05 #3

P: n/a
More simple way? What's that?

Dec 21 '05 #4

P: n/a
gr*****************@spamgourmet.com wrote:
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/sea...&y=0&type=ASPN

but the best read will probably be

http://aspn.activestate.com/ASPN/Coo...n/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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 21 '05 #5

P: n/a
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.

Jan 13 '06 #6

P: n/a
Correction to my last post:

It should say:

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

Jan 13 '06 #7

P: n/a
gr*****************@spamgourmet.com wrote:
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)
--
--Bryan
Jan 14 '06 #8

P: n/a
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.

Jan 14 '06 #9

P: n/a
gr*****************@spamgourmet.com writes:
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....849013e37c995b
Jan 14 '06 #10

P: n/a
gr*****************@spamgourmet.com wrote:
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 14 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.