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

Please support the feature of specifying client local address when it connects to the server #989

Open
SimonLiuhd opened this issue Aug 1, 2022 · 4 comments

Comments

@SimonLiuhd
Copy link

Dear motan team,

When a interface has multiple IP address, we want to specify a IP to connect with the server.
Could you please support the feature of specifying client local address when it cpnnect to the server?

  1. When the client local address parameter is specified,
    We use the io.netty.bootstrap#connect(SocketAddress remoteAddress, SocketAddress localAddress) to build the ChannelFuture instance and then get the io.netty.channel.Channel object;
  2. When the client local address parameter is not specified
    Keep the current logic: use the io.netty.bootstrap#connect(SocketAddress remoteAddress) to build the ChannelFuture instance and then get the io.netty.channel.Channel object;

Thanks a lot.

@SimonLiuhd SimonLiuhd changed the title Please support the feature of specifying client local address when it cpnnect to the server Please support the feature of specifying client local address when it connect to the server Aug 1, 2022
@SimonLiuhd SimonLiuhd changed the title Please support the feature of specifying client local address when it connect to the server Please support the feature of specifying client local address when it connects to the server Aug 1, 2022
@rayzhang0603
Copy link
Collaborator

Motan can specify the ip of the export service (through the host configuration item, MOTAN_IP_PREFIX env, or hostname)on the server side, but why does the client side need to control the ip of the connection?

@SimonLiuhd
Copy link
Author

SimonLiuhd commented Aug 2, 2022

@rayzhang0603
The case is that we use the VIPs for motan RPC communications between client and service.

For HA, the client and the service are both hot standy with two instances in total two pyhsical machines, but at any time point, only one client/server instance works where the client/server VIPs are attached. And client VIP is not the same as service VIP.

When client VIP and server VIP stand on the same pyhsical machine (such machine A), the RPC connection is service-VIP:randomPort -- service-VIP:service-port, when the service is hanged, the service VIP goes to machine B. At this point, the connection is invalid, since the source IP is not on the machine A, but client still uses the invalid remained connetions and it cannot fast fail utill the OS kills the invalid connection per keepalive_timeout.

So, we want to specify the source address (which is the real IP of the phsical machine), not the VIP of client to establish the connection, making the connection as machine A real-IP:randomPort -- service-VIP:service-port in above case before service VIP goes to machine B. when source IP is the real IP, after service VIP goes to machine B, the connection is still valid and can be used to heartbeat.

@rayzhang0603
Copy link
Collaborator

It is not recommended to specify client ip directly in the configuration, so the adaptability of the code will be poor。
After the vip switch, the link should be disconnected. When the connection is re-established, the client will automatically use the appropriate ip.
If you want to perceive the link abnormality as soon as possible, you can use the motan-transport-netty module, When the request fails, the link will be destroyed, and the new request will have the opportunity to re-establish the link

@SimonLiuhd
Copy link
Author

@rayzhang0603
How about we use a JVM parameter (such as -Dmotan.client.ip) to achieve this feture:
When the parameter is configured, and has valid IP address value, we use io.netty.bootstrap#connect(SocketAddress remoteAddress, SocketAddress localAddress) to build the ChannelFuture instance, otherwise keep the current behavior.

I think the above way has littele impact on the code, and this can implements what we wants.
And our applications still are going to have the evolutions with motan.

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

No branches or pull requests

2 participants