01:02:34  * DarkGodquit (Ping timeout: 252 seconds)
06:36:35  * SkyRocknRolljoined
08:39:45  * SkyRocknRoll_joined
08:41:33  * SkyRocknRollquit (Ping timeout: 276 seconds)
09:41:18  * DarkGodjoined
10:08:27  * DarkGodquit (Ping timeout: 244 seconds)
12:01:28  * SkyRocknRoll_quit (Ping timeout: 252 seconds)
13:30:07  * DarkGodjoined
15:12:11  <rphillips>good morning
15:18:15  <creationix>mornin
15:19:16  <creationix>rphillips: are you around today or still trying to rest?
15:25:06  * erlbot--_joined
15:26:59  * erlbot--quit (Ping timeout: 240 seconds)
15:42:08  * travis-cijoined
15:42:10  <travis-ci>luvit/luvi#863 (master - a3ec57f : Tim Caswell): The build passed.
15:42:10  <travis-ci>Change view : https://github.com/luvit/luvi/compare/fa8185289619...a3ec57fe2e89
15:42:10  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/111776438
15:42:10  * travis-cipart
15:44:57  <creationix>interesting conversation about binary modules and luvi https://github.com/luvit/luvi/issues/140#issuecomment-188573479
15:48:09  * visionikquit (Read error: Connection reset by peer)
15:48:43  * ksheedloquit (Ping timeout: 250 seconds)
15:49:09  * visionikjoined
15:49:59  * ksheedlo-raxjoined
15:51:34  <rphillips>creationix: around today
15:51:37  <rphillips>feeling much better
15:52:02  <creationix>I'm glad
15:52:14  <creationix>So I'm finally cleaning up the ssl stuff in coro-*
15:52:57  <creationix>The long-term plan is to modify luv to accept an ssl context for uv_stream_t, but I found a way in the mid-term to simulate that in lua
15:53:08  <rphillips>nice
15:53:27  <creationix>https://github.com/luvit/lit/pull/174
15:53:59  <creationix>basically, there is a new module "secure-socket" that takes an ssl config table and a uv_stream_t and returns a fake uv_stream_t where reading and writing goes through the crypto
15:54:25  <creationix>the main interface will wait for handshake to complete and either return (coroutine style) or pass (callback style) the fake stream back
15:54:46  <creationix>this means it can be shared between luvit and coro-* so we don't need two different wrappers around openssl
15:55:28  <creationix>and when it eventually moves to the C side to avoid all the wasteful interning of cipher-text into lua, the libraries will need minimal changes
15:56:46  <creationix>Also it really cleans up the coro-* ecosystem. Now you can simple pass a tls options table to coro-net and the resulting read/write functions will go through ssl
15:56:52  <creationix>no need for tls-wrapper at all
15:57:38  <creationix>and the newish way of passing encoder/decoders to coro-net now works with tls (you don't have to choose between new way and supporting tls which we had to do before)
15:58:36  <rphillips>very cool
15:58:41  <rphillips>that shold be a nice improvement
15:58:46  <rphillips>should*
15:59:14  <creationix>it also means that nothing needs a dependency on openssl just because it might use tls
15:59:47  <creationix>they can just depend on coro-net. And only *if* they try to use tls, will it notice if openssl is installed or not
15:59:53  <creationix>optional dependency
16:00:36  <creationix>so practically speaking, my servers can all now use luvi tiny since they sit behind nginx for ssl termination
16:00:47  <creationix>or lua or luajit
16:00:56  <creationix>all the other deps are now portable
16:02:36  <creationix>This should be big. It means the general lua community can now use all our core libraries without needing luvit or luvi. Just luv + libraries which are all now in portable format.
16:02:49  <creationix>I'll write up that blog post after I'm done cleaning up and testing all this.
16:16:15  <creationix>rphillips, so how well do you understand tcp?
16:16:31  <rphillips>pretty well
16:16:34  <creationix>I'm having trouble figuring out the expected and desired behavior of coro streams
16:17:12  <creationix>I understand that a duplex stream can be closed on either side (send a FIN), while the other is still sending data?
16:17:25  <creationix>so the two halves seem kinda independent
16:17:55  <creationix>in the coro interface, you write(nil) to end a write stream. It calls uv.shutdown which I assume sends the FIN
16:18:29  <creationix>and on the read side, if you receive a FIN, libuv will pass a EOF to the onRead callback and coro-streams will return nil from read
16:18:53  <creationix>what I don't understand is what should happen if the client disconnects without sending the fin
16:19:29  <creationix>I would expect the OS to tell libuv the socket died and libuv give me either an error or EOF event, but it just does nothing. The onRead callback in C is never called
16:20:06  <rphillips>you will need a read timeout
16:20:10  <creationix>I understand detecting the disconnected socket is difficult if it's idle so I added a heartbeat message that's sent
16:20:32  <creationix>the heartbeat will return EBADF or EPIPE (server or client) if the socket is dead
16:20:44  <creationix>but even then libuv still doesn't ever call onRead
16:21:14  <creationix>a timeout would only work if I'm expecting data. What about long-lived and mostly idle connections?
16:22:27  <rphillips>you can also turn keep alive on but adds some overhead
16:22:29  <creationix>I think I would like read() in the coro-stream to return with an error if the socket is disconnected, but that involves coupling the read and write streams
16:22:47  <creationix>TCP keepalive, yeah that could work
16:23:02  <creationix>that basically just sends heartbeats at the TCP level right?
16:23:44  <rphillips>correct
16:23:52  <rphillips>keep alive is the way to go if the connection is mostly idle
16:24:02  <creationix>I've read several places that keepalive can break some networks, but maybe that's old information
16:24:12  <creationix>I know it's easy to enable using the libuv APIs
16:24:50  <creationix>websocket also has ping/pong and close control frames
16:25:25  <creationix>I'm just not sure what good the websocket level frames does. Attempting to write to a dead socket doesn't trigger onRead to happen
16:25:53  <creationix>I'd have to couple the two halves and abort the read if a write on the same socket failed (just not sure that's a good idea or correct behavior)
16:27:58  <creationix>I think I'll try TCP keepalive. That should be less overhead than websocket control frames
16:29:08  <rphillips>that does sound like correct behavior
16:29:22  <rphillips>if the socket fails the write then it usually needs to be torn down
16:29:42  <creationix>I guess it depends on why the write failed
16:29:54  <creationix>if I send a fin and then try to write, that will fail, but because I closed my write side
16:30:13  <creationix>the read-side might live on for a while in that case I think
16:32:55  <creationix>thanks, I'll see if tcp keepalive does what I want, if not, I'll couple the streams at the higher level
16:39:01  <creationix>the other problem is knowing when to close a socket handle
16:39:27  <creationix>currently coro-net closes after shutdown, but this is wrong, it's too soon
16:39:43  <creationix>I need to couple the two sides and only close after sending and receiving EOF
16:50:57  <rphillips>or an error is thrown
16:55:34  <creationix>so if write returns an error, onRead has an error or both sides have seen EOF, then we need to close the handle
16:55:42  <creationix>that should be enough to prevent leaks I think
16:55:49  <creationix>without closing too soon
19:08:14  <creationix>I wish we had something like npm link, should make this sometime https://github.com/luvit/lit/issues/175
19:16:46  * travis-cijoined
19:16:47  <travis-ci>luvit/luv#202 (master - 767c34b : Tim Caswell): The build passed.
19:16:47  <travis-ci>Change view : https://github.com/luvit/luv/compare/e1777f48a92e...767c34ba3a3d
19:16:47  <travis-ci>Build details : https://travis-ci.org/luvit/luv/builds/111823730
19:16:47  * travis-cipart
20:05:40  * erlbot--_changed nick to erlbot--
20:19:01  <creationix>alright, we got a new lit version