Well in a sense, yes. But even TCP uses unreliable packet based transport under the hood (IP). RUDP is basically reimplementing TCP on top of UDP (in a sense). It's even kind of "defined<http://tools.ietf.org/html/draft-ietf-sigtran-reliable-udp-00>". But yes, it's a contradiction, I have the feeling that a lot of network related things are that way :D
The reason why I need RUDP is NAT traversal (UDP Hole Punching) for a communication software, which is pretty difficult to achieve with TCP actually. Am Montag, 24. Februar 2014 01:07:17 UTC+1 schrieb Guido van Rossum: > > "Reliable UDP"? Isn't that a contradiction? > > On Sunday, February 23, 2014, Christopher Probst < > [email protected] <javascript:>> wrote: > >> Thanks for your help so far, I really appreciate it. >> >> A manual backoff seems the best solution for this weird behavior for now, >> since reliable udp heavily depends on timing this is not such a bad thing >> anyway. >> >> Meanwhile I try to figure out the cause for this issue. >> >> >> Am Montag, 24. Februar 2014 00:31:24 UTC+1 schrieb Guido van Rossum: >>> >>> I still can't repro it with your code. But that doesn't mean it's not a >>> real condition. It sounds like the kind of odd corner of entirely >>> legitimate UDP behavior that is hard to provoke but which a robust app >>> should handle. >>> >>> Note that the default behavior in Tulip appears to be to ignore OSError >>> coming out of sendto() -- the transport calls protocol.error_received(), >>> which by default does nothing. Since there are many other cases where a >>> packet may silently be dropped on the floor, this behavior is technically >>> correct -- the question is whether it is the best default behavior we can >>> imagine. >>> >>> Unfortunately turning it into a pause_protocol() call in your >>> error_received() handler is a little tricky -- the transport remembers >>> whether it has paused the protocol or not, but this state is not public. So >>> you shouldn't call your own pause_writing(), since you'd never receive a >>> resume_writing() call from the transport. Perhaps you can set a flag >>> internal to your protocol that just causes you to back off for a brief >>> period of time? The optimal back-off time should be tuned experimentally. >>> >>> --Guido >>> >>> On Sun, Feb 23, 2014 at 2:45 PM, Christopher Probst < >>> [email protected]> wrote: >>> >>> I made a simpler test, without using tulip, just using plain >>> sockets<http://stackoverflow.com/questions/21973661/os-x-udp-send-error-55-no-buffer-space-available/21973705?noredirect=1#comment33297277_21973705> >>> . >>> >>> from socket import * >>> >>> udp = socket(AF_INET, SOCK_DGRAM) >>> udp.setsockopt(SOL_SOCKET, SO_REUSEADDR, True) >>> >>> udp.bind(('0.0.0.0', 1337)) >>> udp.setblocking(False) >>> udp.setsockopt(SOL_IP, IP_TTL, 4) >>> udp.connect(('8.8.8.8 >>> >>> > > -- > --Guido van Rossum (on iPad) >
