search

weibocom / motan

A cross-language remote procedure call(RPC) framework for rapid development of high performance distributed services.
Other
5.89k stars 1.78k forks source link

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

Open SimonLiuhd opened 2 years ago

SimonLiuhd commented 2 years ago

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.

rayzhang0603 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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.