@runeb dyu mean you added a :timeout to the fast-echo-handler example s/connect ?

@mccraigmccraig yes, precisely. I think the response from @hiredman explains perfectly why I did not see what I initially expected (timeout when lack of incoming data). If timeout is meant to address the tcp layer it makes sense.

manifold.stream/connect :timeout doesn't address the tcp layer... it's timing out a connection between streams, which in the case of the fast-echo-handler is a connection between the rx and tx sides of the tcp socket, but it's not a tcp layer timeout

@mccraigmccraig hmmm in my test case outlined originally (connecting to the handler by way of telnet). Should I expect to see a disconnect from said time out in case I dont touch the keyboard?

no, i don't think so - the only thing being disconnected is the connection between the two streams based on the underlying socket channels - i don't think stream/connect :timeout closes its source or sink

do you observe that it stops echoing after the timeout?

They dont close as far as i cant tell. I set the flags for closing also. I would like to see a disconnect on the telnet side. I need to kick clients that are not chatting for some set period and thought timeout was the answer. I made a watchdog to check "chattiness" of each connection and closing those that fail the timeout threshold. I am curious if this is the expected way of handling such conditions. I am not so sure what benefit I get from the current behavior of timeout? To set tcp socket timeout pr connection instead of on a system level? Do you know?

Hope I make sense 🙂

can you show some code @runeb? easier to understand then...