[erlang-questions] 0MQ libraries

[Erik Søe Sørensen]

Either that's not correct, or the protocol is not reliable. I hope the
first :-)
The buffer in inet is only the tip of the amount of data which have been
sent but may not have received - the OS has (unqueriable) buffers, and
there may be data in transit on the physical level.
Possibly I've misunderstood your description of the problem, but either
way, when it comes to TCP, you're not supposed to be able to get unsent
data back once you've passed it down to lower layers...
Den 31/01/2014 18.43 skrev "Andreas Schultz" <aschultz@REDACTED>:

> Hi,
>
> ----- Original Message -----
> > On Fri, Jan 31, 2014 at 9:44 AM, Andreas Schultz <aschultz@REDACTED>
> wrote:
> >
> > > I got stuck when trying to control the queuing behavior on tcp socket,
> > > gen_tcp hides too much details of the underlying socket and the
> buffering
> > > in it also doesn't help.
> > >
> >
> > Can you remember what specifically your problem was? What controls do you
> > need on the socket in order for it to behave "correctly"? What do you
> mean
> > by queueing behaviour? What do you mean by buffering?
>
> gen_tcp buffers data internal (in the inet code) when it can't sent it
> immediately,
> I haven't found a way to query to amount of data buffered or force a flush
> of the
> buffers.
>
> My specific problem was that after a connection abort, I would not know how
> many of the previous messages where actually sent.
> It can happen that there are for example 1000 messages buffered in gen_tcp
> when
> it decides that the remote side has died. As far as I understood the 0MQ
> semantics,
> I should then try to reestablish the connection and transmit the pending
> messages.
> Without knowing how much was buffered in gen_tcp, that is not possible.
>
> Andreas
>
> >
> >
> > --
> > J.
> >
>
> --
> --
> Dipl. Inform.
> Andreas Schultz
> _______________________________________________
> 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/20140131/53884376/attachment.htm>