Clear UDP socket kernel buffer.

On Aug 17, 3:38 pm, David Schwartz <dav....RemoveThis@webmaster.com> wrote:
> On Aug 17, 2:33 am, gNash <ganeshamu....RemoveThis@gmail.com> wrote:
>
> >  Some case i want to PAUSE (stop receiving for while) the streaming in
> > client.  I'll not worry for the loosing packets which continuously
> > streaming from server.  I am confused to implement this specific
> > please give your ideas or right way to implement this scenario.
>
> Simply stop reading from the socket. When the buffer fills, packets
> will be dropped, which is what you want. When you want to receive
> again, simply resume reading.
>
> DS

Thanks David, but there is some issue..

if you see that idea, when i resume i could receive some old data
(which in kernel buffer) for few moment and new data isn't it ?
This is i want to avoid.

Please give any other suggestions.

Ganesh.

On Aug 17, 3:52 am, gNash <ganeshamu... RemoveThis @gmail.com> wrote:

> Thanks David, but there is some issue..
>
> if you see that idea, when i resume i could receive some old data
> (which in kernel buffer) for few moment and new data isn't it ?
> This is i want to avoid.

I think that's a nonsensical complaint. There is no such thing as
"old" or "new" data. UDP makes no delivery time guarantees. If this
causes you a problem, something is horribly broken elsewhere.

For example, a router may lose its link with your packet in its
buffer. A minute later, the link may come back up and the queue
flushed when the link comes back up. Boom, you get "old" data.

If your application can't deal with this, it's already broken.

> Please give any other suggestions.

When you resume, you can keep reading from the socket until you get a
'would block' indication. This will, typically, flush the queue. But
you are now in the realm of impossible requirements.

UDP simply cannot guarantee that you do not receive a datagram out of
order, long after it was sent. If you need this, your cannot use UDP
and must instead use a protocol that timestamps and/or sequences
datagrams (or do it yourself).

DS

On Aug 17, 4:23 pm, David Schwartz <dav....TakeThisOut@webmaster.com> wrote:
> On Aug 17, 3:52 am, gNash <ganeshamu....TakeThisOut@gmail.com> wrote:
>
> > Thanks David, but there is some issue..
>
> > if you see that idea, when i resume i could receive some old data
> > (which in kernel buffer) for few moment and new data isn't it ?
> > This is i want to avoid.
>
> I think that's a nonsensical complaint. There is no such thing as
> "old" or "new" data. UDP makes no delivery time guarantees. If this
> causes you a problem, something is horribly broken elsewhere.
>
> For example, a router may lose its link with your packet in its
> buffer. A minute later, the link may come back up and the queue
> flushed when the link comes back up. Boom, you get "old" data.
>
> If your application can't deal with this, it's already broken.
>
> > Please give any other suggestions.
>
> When you resume, you can keep reading from the socket until you get a
> 'would block' indication. This will, typically, flush the queue. But
> you are now in the realm of impossible requirements.
>
> UDP simply cannot guarantee that you do not receive a datagram out of
> order, long after it was sent. If you need this, your cannot use UDP
> and must instead use a protocol that timestamps and/or sequences
> datagrams (or do it yourself).
>
> DS

Thanks David.

Sorry i not export in any network programming. i feel sorry for my
assumptions.

i can make out one think from your reply that UDP buffer all the time
hold the latest packet from the network.

i thought the dropping on packet will happen at head of the UDP buffer
(that is incoming packets are discorded and buffer holding
packets are still retained inside the kernel buffer as it is).
i think my assumption entirely wrong.

so, "UDP buffer all the time hold the latest packet from the network",
am i correct Mr.David ?


Thanks again,
Ganesh.

On Aug 17, 4:42 am, gNash <ganeshamu... DeleteThis @gmail.com> wrote:

> so, "UDP buffer all the time hold the latest packet from the network",
> am i correct Mr.David ?

There is no difference. UDP doesn't care when a packet is received and
makes no guarantees about timeliness or order. I think most
implementations will drop packets when the receive queue is full. But
you can simply flush the receive queue by reading packets until you
get a 'would block' indication.

DS

On Aug 17, 4:42 pm, gNash <ganeshamu... DeleteThis @gmail.com> wrote:
> On Aug 17, 4:23 pm, David Schwartz <dav... DeleteThis @webmaster.com> wrote:
>
>
>
> > On Aug 17, 3:52 am, gNash <ganeshamu... DeleteThis @gmail.com> wrote:
>
> > > Thanks David, but there is some issue..
>
> > > if you see that idea, when i resume i could receive some old data
> > > (which in kernel buffer) for few moment and new data isn't it ?
> > > This is i want to avoid.
>
> > I think that's a nonsensical complaint. There is no such thing as
> > "old" or "new" data. UDP makes no delivery time guarantees. If this
> > causes you a problem, something is horribly broken elsewhere.
>
> > For example, a router may lose its link with your packet in its
> > buffer. A minute later, the link may come back up and the queue
> > flushed when the link comes back up. Boom, you get "old" data.
>
> > If your application can't deal with this, it's already broken.
>
> > > Please give any other suggestions.
>
> > When you resume, you can keep reading from the socket until you get a
> > 'would block' indication. This will, typically, flush the queue. But
> > you are now in the realm of impossible requirements.
>
> > UDP simply cannot guarantee that you do not receive a datagram out of
> > order, long after it was sent. If you need this, your cannot use UDP
> > and must instead use a protocol that timestamps and/or sequences
> > datagrams (or do it yourself).
>
> > DS
>
> Thanks David.
>
> Sorry i not export in any network programming. i feel sorry for my
> assumptions.
>
> i can make out one think from your reply that UDP buffer all the time
> hold the latest packet from the network.
>
> i thought the dropping on packet will happen at head of the UDP buffer
> (that is incoming packets are discorded and buffer holding
> packets are still retained inside the kernel buffer as it is).
> i think my assumption entirely wrong.
>
> so, "UDP buffer all the time hold the latest packet from the network",
> am i correct Mr.David ?
>
> Thanks again,
> Ganesh.

Hi
i also want to PAUSE and RESUME very frequently. so i should not have
any data between those state transmission.
the frequent could be fast , so it is better to clear or flush the
data in the kernel.

please give me suggestion for this.

Thanks in advance,

Ganesh.

On Aug 17, 8:41 pm, David Schwartz <dav....RemoveThis@webmaster.com> wrote:
> On Aug 17, 4:42 am, gNash <ganeshamu....RemoveThis@gmail.com> wrote:
>
> > so, "UDP buffer all the time hold the latest packet from the network",
> > am i correct Mr.David ?
>
> There is no difference. UDP doesn't care when a packet is received and
> makes no guarantees about timeliness or order. I think most
> implementations will drop packets when the receive queue is full. But
Thanks,

> you can simply flush the receive queue by reading packets until you
> get a 'would block' indication.

flush, 'would block' indication.. please kindly give me some more
explanation...

Thanks.
Ganesh

> DS

On Aug 17, 8:42 am, gNash <ganeshamu....RemoveThis@gmail.com> wrote:

> Hi
>  i also want to PAUSE and RESUME very frequently. so i should not have
> any data between those state transmission.
> the frequent could be fast , so it is better to clear or flush the
> data in the kernel.
>
> please give me suggestion for this.

You're reaching the point where your design is becoming less and less
rational. It sounds like you're trying to figure out how to put a
screw in with a hammer.

The basic point of illogic is this:

1) It's much harder to send data over a network than to throw data
away in user space.

2) You are perfectly willing to send a huge amount of needless data
over the network.

3) You are unwilling to throw the needless data way.

In what possible situation does it make sense to force the sender to
go to all the trouble of sending data you're unwilling to even go to
the effort of discarding properly?

It's like trying to come up with an efficient shipping center that can
receive and destroy millions of packages without having to go to the
trouble of opening them. If it's okay to go to the trouble of shipping
them across the country, why not just open them before you discard
them?

Why can't you just keep reading from the socket but ignore the data if
you don't want to process it intensively? What are you trying to
avoid? It makes no sense.

DS

gNash wrote:
> On Aug 17, 8:41 pm, David Schwartz <dav... DeleteThis @webmaster.com> wrote:
>> On Aug 17, 4:42 am, gNash <ganeshamu... DeleteThis @gmail.com> wrote:
>>
>>> so, "UDP buffer all the time hold the latest packet from the network",
>>> am i correct Mr.David ?
>> There is no difference. UDP doesn't care when a packet is received and
>> makes no guarantees about timeliness or order. I think most
>> implementations will drop packets when the receive queue is full. But
> Thanks,
>
>> you can simply flush the receive queue by reading packets until you
>> get a 'would block' indication.
>
> flush, 'would block' indication.. please kindly give me some more
> explanation...

Use select() to see if there's anything available to read. If not that's
a "would block" condition.