Python sockets UDP broadcast multicast question??
Hi all, I have a question about python and sockets , UDP datagram in particular. I'm new to socket programming so please bare with me. I am trying to write a simple application that broadcast files to another computer on the same network/subnet but I do not want the receiver computer to have to respond, I only want it to receive the packet. So this was simple enough, but my problem is this when I send a file that is say larger then 100K the receiver is not able to keep up with the packets as they arrive. I get say 60 or so then the rest are ignored. I have tried a couple of different approaches like threading and queuing, but all ultimately have the same problem. So my question is how can I receive a continuous stream of UDP packets to some kind of buffer for processing with out losing packets? Thank you for any help or guidance that you provide. - InOrlando -- http://mail.python.org/mailman/listinfo/python-list
Re: Python sockets UDP broadcast multicast question??
On 28 Ago, 08:09, inorlando [EMAIL PROTECTED] wrote: Hi all, I have a question about python and sockets , UDP datagram in particular. I'm new to socket programming so please bare with me. I am trying to write a simple application that broadcast files to another computer on the same network/subnet but I do not want the receiver computer to have to respond, I only want it to receive the packet. So this was simple enough, but my problem is this when I send a file that is say larger then 100K the receiver is not able to keep up with the packets as they arrive. I get say 60 or so then the rest are ignored. I have tried a couple of different approaches like threading and queuing, but all ultimately have the same problem. So my question is how can I receive a continuous stream of UDP packets to some kind of buffer for processing with out losing packets? Thank you for any help or guidance that you provide. - InOrlando The UDP protocol is defined 'unreliable' because it cannot guarantee in all conditions the delivery of all packets in the correct sequence. This means than in specific conditions, e.g. when the network or one of the communicating computers is overloaded, you can loose packets or receive them in the wrong order. So, first of all, if you cannon tolerate packet loss, consider switching the protocol to TCP. If you cannot change protocol (maybe because TCP has no multicast), then try to reduce the load on the computer and the network, e.g. by inserting a delay between two packet transmissions. But remember that this only reduce, does not cancel, the possibility of packet loss or packet mis-ordering. Of course, it could be a bug in your program, in which case none of the above matters ;) Ciao - FB -- http://mail.python.org/mailman/listinfo/python-list
Re: Python sockets UDP broadcast multicast question??
On Aug 28, 8:06 am, Francesco Bochicchio [EMAIL PROTECTED] wrote: On 28 Ago, 08:09, inorlando [EMAIL PROTECTED] wrote: Hi all, I have a question about python and sockets , UDP datagram in particular. I'm new to socket programming so please bare with me. I am trying to write a simple application that broadcast files to another computer on the same network/subnet but I do not want the receiver computer to have to respond, I only want it to receive the packet. So this was simple enough, but my problem is this when I send a file that is say larger then 100K the receiver is not able to keep up with the packets as they arrive. I get say 60 or so then the rest are ignored. I have tried a couple of different approaches like threading and queuing, but all ultimately have the same problem. So my question is how can I receive a continuous stream of UDP packets to some kind of buffer for processing with out losing packets? Thank you for any help or guidance that you provide. - InOrlando The UDP protocol is defined 'unreliable' because it cannot guarantee in all conditions the delivery of all packets in the correct sequence. This means than in specific conditions, e.g. when the network or one of the communicating computers is overloaded, you can loose packets or receive them in the wrong order. So, first of all, if you cannon tolerate packet loss, consider switching the protocol to TCP. If you cannot change protocol (maybe because TCP has no multicast), then try to reduce the load on the computer and the network, e.g. by inserting a delay between two packet transmissions. But remember that this only reduce, does not cancel, the possibility of packet loss or packet mis-ordering. Of course, it could be a bug in your program, in which case none of the above matters ;) Ciao - FB Anyone else have any comments? Anything? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python sockets UDP broadcast multicast question??
On Aug 28, 1:09 am, inorlando [EMAIL PROTECTED] wrote: Hi all, I have a question about python and sockets , UDP datagram in particular. I'm new to socket programming so please bare with me. I am trying to write a simple application that broadcast files to another computer on the same network/subnet but I do not want the receiver computer to have to respond, I only want it to receive the packet. So this was simple enough, but my problem is this when I send a file that is say larger then 100K the receiver is not able to keep up with the packets as they arrive. I get say 60 or so then the rest are ignored. I have tried a couple of different approaches like threading and queuing, but all ultimately have the same problem. So my question is how can I receive a continuous stream of UDP packets to some kind of buffer for processing with out losing packets? Thank you for any help or guidance that you provide. - InOrlando I am rusty on those. AIR as I recall, if you use UDP, you need to coordinate with the sender what packets you receive and what you don't by use of 'ACK' packets that acknowledge a packet is received. The sender resends any packets that it hasn't received an ACK for. If you want guaranteed receipt, you have to use TCP, as Francesco stated. Still, when transmitting, the 'send' command doesn't guarantee its entire contents are sent. It returns the length that was transmitted, and you must try again with the remaining contents continuously. -- http://mail.python.org/mailman/listinfo/python-list
