-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support UNIX sockets #84
Comments
Are you familiar with how the Julia networking libraries work in the current version of the standard lib? I took a quick look at it seems a bit odd that |
Hmm, I didn't realize Redis.jl did its own socket management. I had assumed (uh-oh!) that it was using a C client under the covers. It looks like |
Yep, this is a pure Julia implementation (for better or for worse 😉). In
that case we may just be able to change the types in connection.jl and
everything should work itself out (or blow up if somehow we are dependent
on tcp, but I doubt it).
…On Mon, Nov 1, 2021, 6:36 PM david-macmahon ***@***.***> wrote:
Hmm, I didn't realize Redis.jl did its own socket management. I had
assumed (uh-oh!) that it was using a C client under the covers.
It looks like Base.PipeEndpoint and Sockets.TCPSocket are both subtypes
of Base.LibuvStream. Once can use methodswith(Base.PipeEndpoint) to see
that it doesn't have any special methods. TCPSocket has a few methods,
but most (all?) of the interesting stuff shows up in
methodswith(Base.LibuvStream).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7FL7H44VG6XCZEVAHAYSTUJ4W77ANCNFSM5HFDYCPQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I think |
Yeah, you're right. I thought the two connect methods accepted the same
argument, but it makes more sense that they don't. Either way should not be
difficult to do.
…On Mon, Nov 1, 2021 at 6:47 PM david-macmahon ***@***.***> wrote:
I think RedisConnection might need a new RedisConnection(; unixsocket)
(or similar) method, but I think that would effectively be the same as the RedisConnection(;host,
port, ...) method since the kwargs don't count towards dispatch. Might
have to roll the new keyword into the existing method and somehow discern
what the caller wants.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7FL7HC3QAXDIEB5FOJXILUJ4YKDANCNFSM5HFDYCPQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I guess one could use |
This adds TLS support. An abstraction for the redis transport `RedisTransport` has been added. The existing TCP transport has been moved in as an implementation `TCPTransport <: RedisTransport`. A new TLS transport has been added as `TLSTransport <: RedisTransport`. This can in future be extended to support unix sockets too (ref: #84) fixes: #87
redis-server can use only UNIX sockets (i.e. no TCP sockets) by setting
port
to 0 andunixsocket
to the pathname of a UNIX socket. Redis.jl only supports TCP sockets currently so it cannot access such a server. Not a big problem if one can configure the server to also bind to a TCP port onlocalhost
, but a very big problem if one does not control the redis-server configuration.The text was updated successfully, but these errors were encountered: