Reputation: 333
I use UDPServer based on BaseServer to receive frag UDP packets .
But some packets are larger than 8192 bytes(@handle method, print len(data)), and I can't use them correctly.
My original code:
class MyUDPHandler(SocketServer.BaseRequestHandler):
def handle(self):
global arr_len_recv
data = self.request[0].strip()
socket = self.request[1]
s_recv_paylaod_len = len(data)
print "s_paylaod",binascii.hexlify(data)
if __name__ == '__main__':
server = SocketServer.UDPServer((HOST, LISTEN_PORT), MyUDPHandler)
tmp = threading.Thread(None, loop_send, None,(param,server) , {})
tmp.daemon=True
tmp.start()
poll=0.1
server.serve_forever(poll)
So I RTFM BaseServer,UDPServer,TCPServer.
python SocketServer documentation
I found in SocketServer.TCPServer Example
class MyTCPHandler(SocketServer.BaseRequestHandler):
def handle(self):
self.data = self.request.recv(1024).strip()
But self.request doesn't have recv method
If you have any solution to fix it or to change max limit of recv buffer.
Upvotes: 4
Views: 4055
Reputation: 333
Finally, I found it in baseserver python source code :
480 class UDPServer(TCPServer):
481
482 """UDP server class."""
483
484 allow_reuse_address = False
485
486 socket_type = socket.SOCK_DGRAM
487
488 max_packet_size = 8192
My modified main (see server.max_packet_size )
if __name__ == '__main__':
server = SocketServer.UDPServer((HOST, LISTEN_PORT), MyUDPHandler)
server.max_packet_size = 8192*2
server.serve_forever()
Upvotes: 4
Reputation: 366103
There are a number of factors involved here.
First, UDP's maximum payload size is 65535. However, the IPv4 header and UDP header count as part of that 65535, so practically speaking, the maximum user-payload size is 65504.
Second, you can't receive more than the smallest receive buffer at any level in the stack. I could explain how to get around this, but I won't, because…
Finally, any packet larger than a single MTU will get fragmented along the way. Unless the fragments just happen to arrive in exactly the same order they were sent, and without any sizable delay, they cannot be reassembled, so you will lose the entire packet. Even on a connection with only 1% Ethernet packet loss, you can expect more than a third of your large UDP packets to be lost. There are very few applications where this is acceptable.
So, what should you do? Well, there are three different answers:
There are some cases where option 2 makes sense—e.g., with many streaming A/V protocols, the audio frames, video iframes, and metadata are all under 1K, and can usually be dropped with no major consequence, so it's not worth the cost of using TCP just to deal with the keyframes, so instead they break the keyframes up into 1K chunks (e.g., rectangular sections of the window) or write explicit TCP-esque check-and-resend code just for keyframes, etc.
But usually, if you need to send large messages around, TCP is going to be a lot easier.
Upvotes: 0