TL;DR:
  1. Does (one of the) libuv wrappers use a recent libuv version (< 6 months ago)?
  2. Does anyone know how to add SSL (in Nim) on top of a libuv wrapper?

I'm still trying to decide what to use for networking. I've noticed there was Nim support for libuv, which I hadn't heard of before (thanks to not wanting to have anything to do with JS and node.js), but I'm not sure if it's used at all. The design of libuv sounds perfect for my use-case.

First, there is libuv from the Standard Library. Based on the comment in the header, which says it was build using this repo, which was "moved" 3 years ago, I have to assume that that module has not been updated for at least 3 years (unless it was, but no one updated the doc for it, and corrected the header). So I guess it's not actually used, otherwise someone would have updated it.

Then there is libuv from the "Unofficial packages", which was updated (created?) "2 months ago", but I can't see any hint about which version of libuv it was based on; it just says "Extracted from Nim standard library", which might mean it is also based on an (at least) 3 years old version of libuv.

When it comes to SSL, it seems libuv team is against integration, because they don't want to "take sides" (choose a specific SSL impl). A bit of research resulted in 2 possible solutions:

  1. uv_ssl_t, which at the same time is described as "HIGHLY UNSTABLE" and has not been updated for 2 years.
  2. evt-tls, which was updated "8 days ago", and used to be called "libuv-tls", but is now a "generic wrapper" over OpenSSL, which, if I understand properly, means I have to build my own wrapper on top, to use with libuv.

In a world where "everyone" gets hacked all the time, I can't relate to "networking libraries/frameworks" which treat "security" as an "optional feature".

2018-01-06 14:57:26
2vg

Please use the rapper I made.

It supports APIs included in the latest version(libuv 1.18.1), and it can be used comfortably as API can be used like the original.

In order to use it, the latest libuv must be installed.(made when libuv 1.18.1)

Since this wrapper is still in beta, please send me a pull request to tell me if there is any problem.

nimuv

this is toy project using my wrapper made by me.

However, it is faster than Rust's tokio-minihttp.

mofuw_uv

If you can do an asynchronous approach yourself, using the event loop of the Selectors module will make for even faster things.

Or, if you do not support Windows, libev will be slightly faster than Selectors.

Here is the wrapper for libev.

nimev

2018-01-07 01:17:24
2vg

I have seen evt-tls now.

dont the code base to look so big, so I would like to write a wrapper or implement it pure.

2018-01-07 01:37:29

@2vg Nice! I'm going to give it a try. I do need to support Windows; that is my primary target for the client (the server will be primarily Linux).

I won't need encryption until I release the first alpha version, and I'm a long way away. If you plan to have a look at SSL support, that would be great.

2018-01-07 11:28:11
I don't see the need for wrapping what is better covered by Nim's stdlib. 2018-01-10 08:05:28
@Araq Sorry if I'm a bit slow on the uptake, but I'm not sure about what you meant. libuv is wrapped in the stdlib, which is great, but if it's really based on a 3+ yo version (is it?), AND libuv is updated regularly, which it is, then I do see the need for a non-stdlib that is more recent. If what you meant is that we should stick to the stdlib wrapper, and it sounds like that to me, then I guess you would like a pull-request instead of a third-party wrapper? And if you meant something else, then you lost me. 2018-01-11 18:57:59
2vg

perhaps Araq is talking about SSL wrapping.

looking at devel, it seems that the wrapper of libuv has been delete.

https://github.com/nim-lang/Nim/tree/devel/lib/wrappers

2018-01-12 00:26:22
I suspect Araq suggests using stdlib asyncdispatch instead of libuv.
2018-01-12 08:20:15

@yglukhov Maybe, but if I understand asyncdispatch propertly, it's really not comparable to libuv. I haven't checked the implementation of asyncdispatch, but it looks to me as if, under the hood, it's still one-thread-per-blocking-IO-call. So If I was listening to 100 sockets, it would need 100 threads? If that is the case, then asyncdispatch simply isn't an option for me, as it won't scale well.

@2vg Well, if the libuv wrapper was deleted from devel, then Araq couldn't possibly have been implying that SSL support for libuv should belong to stdlib. We'll just have to wait for Araq to reply.

2018-01-13 11:32:08
<<<••12••>>>