flushing a socket buffer

Hi friends,

I've a networking application, which is having some pre-configured
memory (region and pool), from which application supposed to allocate
buffer to read data from socket.
The application will not read data from the receive buffer (in kernel)
when it's not able to allocate memory (due to out of resource). This
will cause recieve buffer to overflow as peer is continuously sending
data.

The question is, I'd like to know if we can flush out the receive
buffer without reading into application?. I don't want to read the
"old" data present in the receive buffer ?
Is there any way to do this?

Any suggestions would be greatly appreciated.

Thanks in advance,
-Soj

soj <jul.sfx@gmail.com> wrote:
> The question is, I'd like to know if we can flush out the receive
> buffer without reading into application?. I don't want to read the
> "old" data present in the receive buffer ? Is there any way to do
> this?

You could close() the socket and open a new one.

If this is a socket bound to a UDP endpoint, you will have a window
where the remote sender could be triggering ICMP Destination
Unreachable, Port Unreachable (IIRC) messages which may or may not be
sent back to the remote application.

With UDP, unless you can guarantee you will be keeping-up with the
stream, you probably want to implement some sort of application-level
flow control between your end and the remote...

If this is a socket bound to a TCP endpoint (probably not since you
mention overflow, but trying to be complete...), you will have a
window where the remote sender will probably trigger RST segments. Of
course, if this is a TCP endpoint, the TCP flow control likely means
that the remote sender got flow-controlled and there may not be all
that much "new" data in the first place. The remote has to know to
reconnect...

Otherwise, I'm pretty sure that the only (portable at least) thing to
do is just read the data from the socket and not do anything with it.

Now, that new-fangled (perhaps egg-laying-wolly-milk-pig :) SCTP has,
IIRC a way to specify the timliness of data to SCTP and have it drop
it all on its own... no idea if all the systems involved in what you
want to do include support for SCTP.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Thanks Rick,

But I still wondering there is no way to just flush out data from the
receive buffer ?
I searched a lot to get ride of this.. but no avail :( and seems like
socket options are also of no help here..
Here, is my case, I can't read data from socket as I dont have enough
memory to allocate.

Rgds,
-soj

On Mar 20, 10:50 pm, Rick Jones <rick.jon...@hp.com> wrote:
> soj <jul....@gmail.com> wrote:
> > The question is, I'd like to know if we can flush out the receive
> > buffer without reading into application?. I don't want to read the
> > "old" data present in the receive buffer ? Is there any way to do
> > this?
>
> You could close() the socket and open a new one.
>
> If this is a socket bound to a UDP endpoint, you will have a window
> where the remote sender could be triggering ICMP Destination
> Unreachable, Port Unreachable (IIRC) messages which may or may not be
> sent back to the remote application.
>
> With UDP, unless you can guarantee you will be keeping-up with the
> stream, you probably want to implement some sort of application-level
> flow control between your end and the remote...
>
> If this is a socket bound to a TCP endpoint (probably not since you
> mention overflow, but trying to be complete...), you will have a
> window where the remote sender will probably trigger RST segments. Of
> course, if this is a TCP endpoint, the TCP flow control likely means
> that the remote sender got flow-controlled and there may not be all
> that much "new" data in the first place. The remote has to know to
> reconnect...
>
> Otherwise, I'm pretty sure that the only (portable at least) thing to
> do is just read the data from the socket and not do anything with it.
>
> Now, that new-fangled (perhaps egg-laying-wolly-milk-pig :) SCTP has,
> IIRC a way to specify the timliness of data to SCTP and have it drop
> it all on its own... no idea if all the systems involved in what you
> want to do include support for SCTP.
>
> rick jones
> --
> Process shall set you free from the need for rational thought.
> these opinions are mine, all mine; HP might not want them anyway... :)
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

soj <jul.sfx@gmail.com> wrote:
> But I still wondering there is no way to just flush out data from
> the receive buffer ? I searched a lot to get ride of this.. but no
> avail :( and seems like socket options are also of no help here..
> Here, is my case, I can't read data from socket as I dont have
> enough memory to allocate.

Nothing says you cannot just overwrite the same smallish buffer until
you've drained as much as you like. Heck, in _theory_ you could read
into a single-byte buffer over and overagain to do the drain - however
that may take more cycles than normal processing.

It could even be a "buffer" on the stack rather than something
allocated from the heap. Or you allocate a suitably sized "bit bucket
buffer" at initialization on the assumption you will need it later.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...