put to websocket stream when router went down?

[Keith Irwin]

I’m using the web socket client on a local device to talk to a remote host.

What does it mean when I get “false” back when I stream/put! to the stream returned by the websocket-client?

Does it unambiguously indicate that the web socket is down (say, via a pulled network cable, or dropped router somewhere out there)?

I realize that doing a stream/take! on a web-socket under those conditions can take a long time to timeout given the way TCP works.

Is it safe to assume that a “false” for stream/put! means I should assume the connection is broken?

Keith

[Zach Tellman]

That's correct, a `false` return value means the stream is closed, which
means the underlying connection is closed.

I’m using the web socket client on a local device to talk to a remote host.
What does it mean when I get “false” back when I stream/put! to the stream
returned by the websocket-client?
Does it unambiguously indicate that the web socket is down (say, via a
pulled network cable, or dropped router somewhere out there)?
I realize that doing a stream/take! on a web-socket under those conditions
can take a long time to timeout given the way TCP works.
Is it safe to assume that a “false” for stream/put! means I should assume
the connection is broken?
Keith
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Keith Irwin]

When I pull the network cable on my device, my browser client (using web sockets to an Aleph back end) dies right away.

However, the JVM client can still put to the web-socket stream and get “true” back for over a minute or so (on OS X) after the route to the remote host is broken via cable-pull.

I’ve also got something waiting to `take!` from the stream, which is where I finally detect that the network is down and handle it (but waiting for recv to detect a disconnected network has taken up to 10 minutes where I’ve deployed this).

My mistake was in not using the result of the put!, but even so, shouldn’t the first attempt to send something across the web-socket after the network cable is pulled result in a “false” of some sort?

That’s an actual question. Perhaps I’m missing some property of TCP networking in general?

That's correct, a `false` return value means the stream is closed, which means the underlying connection is closed.
I’m using the web socket client on a local device to talk to a remote host.
What does it mean when I get “false” back when I stream/put! to the stream returned by the websocket-client?
Does it unambiguously indicate that the web socket is down (say, via a pulled network cable, or dropped router somewhere out there)?
I realize that doing a stream/take! on a web-socket under those conditions can take a long time to timeout given the way TCP works.
Is it safe to assume that a “false” for stream/put! means I should assume the connection is broken?
Keith
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Keith Irwin]

When I test sends with:

(defn- good-conn?
[]
(let [s (java.net.Socket.)]
(try
(.connect s (java.net.InetSocketAddress. “remote.local" 60001) 2000)
(.close s)
"Ok"
(catch Throwable t
(.close s)
(str t)))))

I get the “disconnected” message after pulling the cable:

(defn- do-send!
[stream data]
(if (sendable? state)
(let [rc @(stream/put! stream data)]
(log/info " - send: " rc, ", socket:" (good-conn?))
rc)
true))

Logs something like:

21:03:29 - send: true , socket: Ok
21:03:29 - send: true , socket: Ok

Pull cable or SysPrefs “off” the network.

21:03:32 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:32 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:42 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:42 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:52 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:52 - send: true , socket: java.net.ConnectException: Network is unreachable

Restore the network.

21:04:00 - send: true , socket: Ok
21:04:00 - send: true , socket: Ok

Shows pulling the network cable, then restoring it.

Should I read this as aleph/manifold/stream/netty buffering up messages under stormy network connections?

Post by Keith Irwin
When I pull the network cable on my device, my browser client (using web sockets to an Aleph back end) dies right away.
However, the JVM client can still put to the web-socket stream and get “true” back for over a minute or so (on OS X) after the route to the remote host is broken via cable-pull.
I’ve also got something waiting to `take!` from the stream, which is where I finally detect that the network is down and handle it (but waiting for recv to detect a disconnected network has taken up to 10 minutes where I’ve deployed this).
My mistake was in not using the result of the put!, but even so, shouldn’t the first attempt to send something across the web-socket after the network cable is pulled result in a “false” of some sort?
That’s an actual question. Perhaps I’m missing some property of TCP networking in general?

That's correct, a `false` return value means the stream is closed, which means the underlying connection is closed.
I’m using the web socket client on a local device to talk to a remote host.
What does it mean when I get “false” back when I stream/put! to the stream returned by the websocket-client?
Does it unambiguously indicate that the web socket is down (say, via a pulled network cable, or dropped router somewhere out there)?
I realize that doing a stream/take! on a web-socket under those conditions can take a long time to timeout given the way TCP works.
Is it safe to assume that a “false” for stream/put! means I should assume the connection is broken?
Keith
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups "Aleph" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Zach Tellman]

I think you should read that as TCP not giving up even under adverse
conditions. I would guess the browsers are trying to more proactively
explain why things aren't working, but it takes time for a connection to
close without a RST packet.

Post by Keith Irwin
(defn- good-conn?
[]
(let [s (java.net.Socket.)]
(try
(.connect s (java.net.InetSocketAddress. “remote.local" 60001) 2000)
(.close s)
"Ok"
(catch Throwable t
(.close s)
(str t)))))
(defn- do-send!
[stream data]
(if (sendable? state)
(log/info " - send: " rc, ", socket:" (good-conn?))
rc)
true))
21:03:29 - send: true , socket: Ok
21:03:29 - send: true , socket: Ok
Pull cable or SysPrefs “off” the network.
21:03:32 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:32 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:42 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:42 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:52 - send: true , socket: java.net.ConnectException: Network is unreachable
21:03:52 - send: true , socket: java.net.ConnectException: Network is unreachable
Restore the network.
21:04:00 - send: true , socket: Ok
21:04:00 - send: true , socket: Ok
Shows pulling the network cable, then restoring it.
Should I read this as aleph/manifold/stream/netty buffering up messages
under stormy network connections?
When I pull the network cable on my device, my browser client (using web
sockets to an Aleph back end) dies right away.
However, the JVM client can still put to the web-socket stream and get
“true” back for over a minute or so (on OS X) after the route to the remote
host is broken via cable-pull.
I’ve also got something waiting to `take!` from the stream, which is where
I finally detect that the network is down and handle it (but waiting for
recv to detect a disconnected network has taken up to 10 minutes where I’ve
deployed this).
My mistake was in not using the result of the put!, but even so, shouldn’t
the first attempt to send something across the web-socket after the network
cable is pulled result in a “false” of some sort?
That’s an actual question. Perhaps I’m missing some property of TCP
networking in general?
That's correct, a `false` return value means the stream is closed, which
means the underlying connection is closed.

I’m using the web socket client on a local device to talk to a remote host.
What does it mean when I get “false” back when I stream/put! to the
stream returned by the websocket-client?
Does it unambiguously indicate that the web socket is down (say, via a
pulled network cable, or dropped router somewhere out there)?
I realize that doing a stream/take! on a web-socket under those
conditions can take a long time to timeout given the way TCP works.
Is it safe to assume that a “false” for stream/put! means I should assume
the connection is broken?
Keith
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.