Unix Domain Sockets & Redis / MongoDB

[etcimon]

I've seen a 15-25% improvement in performance using Unix Domain Sockets, they've been implemented in libasync earlier this summer and on my experimental fork of vibe.d, if you'd like to review, I'll be able tp do a diff and start merging some things in the near future.

See below:

https://github.com/etcimon/vibe.0/blob/master/source/vibe/core/drivers/libasync.d#L338

https://github.com/etcimon/vibe.0/blob/master/source/vibe/db/redis/redis.d#L913

By the way, I might have some time to work on the http/2 and cookiejar pulls as well if you hadn't abandoned them. It has been quite stable on my end, I just need to develop a MemoryCookieJar too now :)

[s-ludwig]

There have been some first UDS additions recently (#1547), so it should fit in nicely, with libevent also supporting them. The only difference AFICS is that that pull reuses connectTCP instead of defining a separate connectUDS - ideally the functions within the driver should be called connectStream and connectDatagram, but that change is left for the new vibe-core package.

My plan is to finish vibe-core first and then devote some serious time for working on the HTTP/2 and cookie jar code. It may look quite different in the end (don't know yet), because I wanted to do a full revamp of the HTTP server module and the final stream design isn't fully clear yet. I could, instead of using the old http2 branch, also use your latest fork as the basis. I guess it will be less work overall, considering that the code will change a lot anyway.

[etcimon]

ideally the functions within the driver should be called connectStream and connectDatagram, but that change is left for the new vibe-core package.

I think that would be good, although my only complaints about these type of factory functions are that you don't know what exact type they would return from their declarations, which is mild annoyance when matched with IDEs. After all, is there anything else than TCP and UDS in the core, unless you allow registration of custom constructors e..g redis?

I could, instead of using the old http2 branch, also use your latest fork as the basis. I guess it will be less work overall, considering that the code will change a lot anyway.

I remember reading through your every commits regarding the changes that made up the http/2 branch, and I think the bulk of them were about removing the ManualEvent.emitLocal and Task.priority and adjusting it to the existing server/client implementations. I removed emitLocal on the new version but Task.priority remains. It seems useful for me to be able to schedule priorities of Tasks in particular when using the semaphore for queuing workloads in redis/postgresql/mongodb/etc, I think it would be worth additional consideration.

[schveiguy]

I'm also interested in redis using UDS. Using TCP opens the redis store up to anyone who has access to the network. Even if you bind it to localhost, generally the password is stored in clear text in the config file (if you want to use one). Using Unix sockets, I can use the filesystem permissions to secure the redis server. So I can use TCP for now, but would love to close this security hole in the future.

Note, that you could make (at least redis) work with the existing API since port 0 means "don't bind to network". The server string could then be interpreted as a file on the filesystem to use.