-
Notifications
You must be signed in to change notification settings - Fork 481
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
URI bind/connect parsing error in zmq.io.net.tcp.TcpAddress::resolve(..) #874
Comments
@fredoboulo thanks for the links. I started to extend this (which is/should be technically simple) but encountered some stumbling blocks, maybe you could advise how to proceed: The usage of the asterisk '
Would be willing to dive a bit more into the code, modify it where necessary but am a bit worried that'll it be for nothing if these proposed changes (ie. endpoints following URI semantics, Java 11) which are close to the core are perceived to be too much... Your input would thus be much appreciated. |
The library aims to support Android usage, which means almost-Java-8. Can you point which unit tests in Jeromq are omitting the scheme/protocol? |
Pretty much all in TcpAddressTests except for I thought of generalising @Override
public InetSocketAddress resolve(String name, boolean ipv6, boolean local)
{
if (name == null) {
throw new IllegalArgumentException("declared TCP endpoint is null");
}
final URI uri = URI.create(name.replace("*", ipv6 ? "::" : "0.0.0.0"));
final String newHost = uri.getHost();
final int newPort = uri.getPort();
final String path = uri.getPath();
// [..]
} There are also some parts in It's of course possible to change all the unit-tests accordingly, but this may (or not) surprise some users that relied on this implicit behaviour. The first PR would have simply ignored the path argument -- as it should with the present definition. Then -- as a second step (another PR) -- I would have propagated the
Well, then I should be probably looking for an Android-compatible JDK8 if I want to get anything merged. :-) N.B. my IDE refuses to compile/run with the deprecated |
We are implementing a Majordomo broker derivative that uses in addition to the
ROUTER
alsoXPUB
andSUB
socket types for communicating with external/internal clients and workers.In order to distinguish the endpoints, we bind these sockets internally to:
which works fine.
In order to keep this symmetric for external clients/workers and to stick to the RFC 3986 URI convention (ie.
scheme:[//authority]path[?query][#fragment]
), the same sockets are also individually bound to external IP:port addresses.I'd like to simply replace the 'broker' authority part with a specific 'IP:port' address (not necessarily all the same for each socket), for example 'tcp://localhost:5050/router', which presently fails in TcpAddress::resolve(..) with
since the parser assumes that there is only one number in the
portStr
after theaddStr
and colon:port = Integer.parseInt(portStr);
Binding several different sockets (but with different paths) on the same port aside, it would be nice if the addressing scheme could be fixed, honour the RFC URI convention, and either
a) ignore the additional
path
component, orb) use the additional
path
information as an additional specifier similar to the 'inproc:////' syntax.Maybe, at the same time, it would be worthwhile to reduce a lot of this custom/redundant code with the existing java.net.URI class implementation that handles a lot of the parsing and syntax checking.
A feature request that is related, but goes beyond this issue: would it be conceivable to use the 'path' argument as a differentiating feature to allow binding multiple sockets to the same TCP port ie. same port but different paths as for the 'inproc://' implementation? This would keep the implementation between both low-level protocols a bit more symmetric and cleaner.
The text was updated successfully, but these errors were encountered: