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

On 28 Ago, 08:09, inorlando <inorla...@gmail.com> 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

On Aug 28, 8:06*am, Francesco Bochicchio <bock...@virgilio.it> wrote:
> On 28 Ago, 08:09, inorlando <inorla...@gmail.com> 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?

On Aug 28, 1:09*am, inorlando <inorla...@gmail.com> 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.