[erlang-questions] socket unrecv

CGS cgsmcmlxxv@REDACTED
Sun Jun 10 00:27:38 CEST 2012

Hi Benoit,

Forgive my lack of imagination, but how do you manage to listen to the same
socket with another process? Can you pass the socket from the other API?
Moreover, how do you make the other API to listen after your one without
putting it in front of the other API?

If you can access and pass the socket from the other API, I think you can
bounce back the data toward the same socket (gen_tcp:send/2) because then
the other API should receive the same data as the original transmitter
(hopefully, the other side won't crash because it doesn't expect reply).
But, still, this is only in the case you can receive the packets in the
same time with the other API and the other API trashes the original packets
(otherwise you just double the data in the other API).


On Sat, Jun 9, 2012 at 4:13 PM, Benoit Chesneau <bchesneau@REDACTED> wrote:

> gen_tcp has the undocumented function `unrecv/2` which is using
> `inet(6)_tcp:unrecv/2` but I don't see the equivalent in the SSL
> module.
> Is there any way in the standard library to fill a buffer in the socket ?
> My use case is the following: I have an api that read some data from
> the socket then pase it and keeps the rest in a buffer. Now I want to
> use this buffer with another API that only read from the socket. I
> could of course make a change in this API to read the data from a
> buffer if it`s available, but since I don't control this API it will
> make some time to have this change included. So rather to say to
> others to use my own patched API in between, I could use this trick.
> So if there is a way to put back the data in the socket pid ?
> - benoît
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120610/88ad4d7d/attachment.htm>

More information about the erlang-questions mailing list