TJ

queue should fallback on connected peers when available

1

seems like our behaviour right now is to wait for that socket to establish a connection, which may or may not ever happen, but if other peers are connected we...

(atop?) would be awesome to get some insight into how messages are routed around, queue sizes etc. preferably this could be done with some sort of logging so that the...

timeout and/or re-send REQ/REP replies?

3

if there's no response and a pipe breaks etc that callback will be in limbo. in many cases this may not matter at all, we could just timeout and error...

not new ones like currently

multiplexed streams. write end: ``` js var axon = require('..'); var fs = require('fs'); var c = axon.socket('channel'); c.bind(3000); var files = [ 'lib/sockets/channel.js', 'lib/sockets/pub.js', 'lib/sockets/sub.js', 'lib/sockets/pull.js', 'lib/sockets/push.js' ] files.forEach(function(file){...

pub-end filtering

3

for subscriptions. back when we were going the router/dealer route propagation would have been a bit more annoying but now that we would just relay with pub/sub all the way...

better queue flushing

2

if a client is having a bad time we shouldn't be plastering it with a large queue on connection haha :D, this could easily lead to thrashing. normally this would...

note to self

when all have closed, currently we handle some of this as if there was only one connect(), same with "connect" event etc. we can have say "socket close" or similar...