Я запускаю сервер GRPC (сервер A), прослушивающий определенный порт. Я хочу иметь возможность отправлять сообщения на другой сервер (сервер B), и чтобы сервер B записывал входящий адрес соединения с сервером A, чтобы он мог позже связаться с сервером A.
На сервере A я прослушиваю порт и создаю такой контекст:
lis, err := net.Listen("tcp", "0.0.0.0:6000")
ctx, cancel := context.WithTimeout(context.Background(),
10000*time.Millisecond)
Затем создайте такое соединение:
connection, err = grpc.DialContext(ctx, server2Address,
grpc.WithInsecure(), grpc.WithBlock())
Перед окончательной отправкой сообщения конечной точке на сервере B, которая пытается прочитать IP-адрес входящего соединения сервера A.
info, _ := peer.FromContext(ctx)
fmt.Printf(info.Addr.String()) // Returns a random port, NOT 6000,
Однако результирующий порт, напечатанный сервером B, является случайным, например 62056, а не 6000, как предполагалось. Я предполагаю, что на сервере A GRPC набирает номер со случайного порта — можно ли заставить GRPC набирать номер с порта 6000, а не со случайного порта?
Почему вас волнует номер порта на стороне клиента? Какую более серьезную проблему вы пытаетесь здесь решить? — person JTApps schedule 30.07.2019
Сервер A знает адрес и порт сервера B, но не знает обратного. Каким-то образом мне нужно сообщить серверу B адрес и порт сервера A, чтобы сервер B мог в будущем связываться с сервером A. Итак, я пытаюсь очистить эту информацию из контекста, предоставляемого входящим сообщением от сервера A до Сервер B, однако, номер порта неточный, поэтому этот пост. — person JTApps schedule 30.07.2019
почему бы не разместить службу gRPC на сервере A на хорошо известном порту, чтобы сервер B мог отвечать напрямую? Вы пытаетесь сделать это для обработки конкретной транзакции и вам нужно поддерживать состояние транзакции? Если это так, я бы использовал обмен токенами, а не какой-то потенциально сложный канал связи. — person JTApps schedule 30.07.2019