Skip to content
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

Udp parser #3075

Merged
merged 2 commits into from
May 3, 2018
Merged

Udp parser #3075

merged 2 commits into from
May 3, 2018

Conversation

simias
Copy link
Contributor

@simias simias commented May 2, 2018

This code contains two independent albeit related commits:

  • The first adds unit tests for the udp_address code

  • The 2nd replaces the current ad hoc parser with the new ip_resolver code

Let me know if you prefer to have two different PRs.

The new resolver code should not break any existing URLs, however it will allow things that didn't work previously such as connecting hostnames (udp://zeromq.org:5555), binding NIC names (udp://eth0:1234) and wildcard ports (udp://127.0.0.1:*).

int rc = addr.resolve (name_, bound);

if (dest_addr_ == NULL) {
TEST_ASSERT_EQUAL (-1, rc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe check for a specific errno here?

@@ -111,7 +109,9 @@ static void test_resolve_ipv4_connect_any ()

static void test_resolve_ipv4_connect_anyport ()
{
test_resolve ("127.0.0.1:*", NULL);
// Not sure if that's useful but the TCP code allows it so why
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Does this have a defined behaviour on any platform? If not, it should be disallowed IMO.
The same applies to TCP.

@bluca
Copy link
Member

bluca commented May 3, 2018

Maybe the TCP address validating code from zmq::socket_base_t::connect should be moved into ip_resolver as well? I'm not sure what's the reason to have it here, or why the code defers the address resolution "until a socket is opened".

Feel free to move it. The reason the resolution is async is that first of all it might block, and secondly the remote endpoint might not be reachable or resolvable until much later. This is a feature of libzmq.

@simias
Copy link
Contributor Author

simias commented May 3, 2018

@bluca if resolution can potentially happen much later maybe it's not a good idea to remove this code? Otherwise it will change the current behavior where you get an early error in case of an invalid URL. The port test could and probably should be added to the ip_resolver anyway, for good measure.

@bluca
Copy link
Member

bluca commented May 3, 2018

Right, I thought by moving you mean refactoring into a function that is still called from the same place so that it can be reused.
In that case please leave it there, as an initial sanity check, however limited and flawed it can be, is useful.

@simias
Copy link
Contributor Author

simias commented May 3, 2018

Currently the UDP code doesn't delay the resolution (should it?) so there wouldn't be anything to reuse really. I'm about to make a PR to add the test to ip_resolver anyway, as it probably makes sense to have it here at any rate.

@bluca
Copy link
Member

bluca commented May 3, 2018

Currently the UDP code doesn't delay the resolution (should it?)

I think it should, yes, to get feature parity with TCP - but don't consider that blocking for the stuff you are working on. Maybe we can open an issue.

simias added 2 commits May 3, 2018 14:22
Solution: replace it with the ip_resolver code shared with the TCP
address code

It simplifies the UDP parsing code and makes it behave more like the
TCP counterpart, in particular it's not possible to connect to hosts
by name and bind by NIC names.

It also adds support for "*" port resolving to 0 (useful to let the OS
allocate the port number).
@simias
Copy link
Contributor Author

simias commented May 3, 2018

(Sorry for the double push)

Rebased the code to remove support for wildcard port on connect, added check for errno in unit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants