-
Notifications
You must be signed in to change notification settings - Fork 284
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
Add Unix domain socket support for listenTCP/listenHTTP for libevent on Posix #2073
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: vibe-core
is the new default (already in master), so it might make sense to add support for this too, before rolling out such a feature.
{ | ||
bind_addr.family = AF_UNIX; | ||
sockaddr_un* s = bind_addr.sockAddrUnix(); | ||
enforce(s.sun_path.length > address.length, "Unix sockets cannot have that long a name."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"that long a name" - it's generally good to be explicit in the error messages. The second part of enforce
is lazy, so you can use things like format
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this needs to be >=
as \0
takes up space too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same enforce and message that was used for the UDS implementation of requestHTTP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phobos doesn't seem to specify the length either, but I could change it to enforce(s.sun_path.length > address.length, "Unix sockets cannot have names longer than %d characters.".format(s.sun_path.length - 1));
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't have to be >=
, s.sun_path
is a byte[]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICS, the path must always be \0
terminated regardless of the buffer length defined in sun_path
, so using >=
seems to be necessary indeed. The stdcpy
below could otherwise also produce a buffer overflow when writing the zero byte.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're copying from address
(string
) to sun_path
(byte[somelength]
). Wouldn't >
rather than >=
make sure sun_path
is large enough to hold address
and \0
?
sockaddr_un* s = bind_addr.sockAddrUnix(); | ||
enforce(s.sun_path.length > address.length, "Unix sockets cannot have that long a name."); | ||
s.sun_family = AF_UNIX; | ||
() @trusted { strcpy(cast(char*)s.sun_path.ptr,address.toStringz()); } (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The toStringz
seems to be unnecessary here. Why don't you simply copy it over (e.g. s[] = address[]
) and then set the next char to \0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also copied from the UDS implementation of requestHTTP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s.sun_path
is a byte[]
. It could be changed to () @trusted { s.sun_path[0 .. address.length] = (cast(byte[])address)[]; s.sun_path[address.length] = '\0'; } ();
, which is more or less what Phobos does. Would that be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be better in many cases because it always avoids a GC allocation, while toStringz
needs to allocate if the string is not already zero terminated in memory for some reason (e.g. string literal or in a buffer that is padded with zeros).
"dependencies": { | ||
"vibe-d:http": {"path": "../../"}, | ||
"vibe-d:web": {"path": "../../"}, | ||
"vibe-d:core": {"path": "../../"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW you would only need vibe-d:web
- it properly specified the dependencies on the other modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think I copied this from another example's dub.json. Might be worth taking a look at others to see if they have unnecessary dependencies as well then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vibe-d:core
is still required for the server example so the libevent
configuration can be used for it, otherwise dub would say The sub configuration directive "vibe-d:core" -> "libevent" references a package that is not specified as a dependency and will have no effect.
. Removing the vibe-d:http
dependency from the server example and vibe-d:web
from the client example though.
import vibe.inet.url; | ||
import vibe.http.server; | ||
import vibe.http.router; | ||
import std.stdio; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use vibe.core.log
for logging and in this case this looks like a left over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah sorry, that's a leftover, will fix that.
auto settings = new HTTPServerSettings; | ||
settings.bindAddresses = ["/tmp/vibe.sock"]; | ||
|
||
listenHTTP(settings, router); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have a look at the other tests for examples on how you can verify the output of the server with requestHTTP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will check that out, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not sure how much sense it would make adding tests for this PR considering the client side (i.e. requestHTTP
, in master since 33027ee) for UDS doesn't have tests either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would surely be good to add a test that tests both sides at once with a simple request. But since it depends on vibe-core fixes to make it work there, too, I'd defer that, though and treat this topic WIP in the meantime.
@wilzbach |
import core.sys.posix.sys.un; | ||
import core.stdc.string : strcpy; | ||
|
||
if (address[0] == '/') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This disallows relative paths, is that necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but we couldn't simply check if it's a valid path because an IP address might also be a valid path.
@s-ludwig Any objections to using std.path.isValidPath(address) && std.socket.getAddressInfo(address, AddressInfoFlags.NUMERICHOST).empty
here? Or is there a way to do this with vibe.core
?
We could also just change it to address.canFind('/')
, but then we wouldn't support Windows paths and paths below the working directory without ./
.
I'm interested in UNIX socket implementations for vibe.d and landed on this page. Is this still, or already a thing? Simply to be informed. |
AFAICS, there are three open review comments that keep this from getting merged. @lesderid, if you don't have time to address them, I could probably take care of them in the near future, so that the remaining changes don't get lost here. |
@s-ludwig I should have time to get back to this PR this week or the next. Sorry for waiting so long with this. |
No description provided.