Thanks Eberhard for the reply and suggestion on the workaround.
Yes, After going through a little bit of grpc source code we could figure
out that
/// Enlists an endpoint \a addr (port with an optional IP address) to
/// bind the \a grpc::Server object to be created to.
///
*/// It can be invoked multiple times.*
///
/// \param addr_uri The address to try to bind to the server in URI form. If
/// the scheme name is omitted, "dns:///" is assumed. To bind to any
address,
/// please use IPv6 any, i.e., [::]:<port>, which also accepts IPv4
/// connections. Valid values include dns:///localhost:1234, /
/// 192.168.1.1:31416, dns:///[::1]:27182, etc.).
/// \param creds The credentials associated with the server.
/// \param[out] selected_port If not `nullptr`, gets populated with the port
/// number bound to the \a grpc::Server for the corresponding endpoint after
/// it is successfully bound by BuildAndStart(), 0 otherwise.
AddListeningPort
/// does not modify this pointer.
ServerBuilder& AddListeningPort(
const std::string& addr_uri,
std::shared_ptr<grpc::ServerCredentials> creds,
int* selected_port = nullptr);
std::vector<Port> ports_;
struct Port {
std::string addr;
std::shared_ptr<ServerCredentials> creds;
int* selected_port;
};
As you have suggested, we have followed this approach and it has worked
fine.
Thanks & Regards,
Nag.
On Friday, October 29, 2021 at 6:23:50 PM UTC+5:30 Eberhard Ludwig wrote:
> No, it is not possible. But this is not a gRPC problem, this is a problem
> of TCP and SSL/TLS. How should the receiver know if the packet is encrypted
> or not? How should the server know if the SSL/TLS handshake shall happen or
> not?
> But you can do the following "workaround":
> Assign two IP addresses to the same machine. Bind the unencrypted port to
> one of both IP addresses and bind the encrypted port to the other IP
> address. So, do not use 0.0.0.0 at AddListeningPort(), but a specific IP
> address. If you have these two different IP addresses, then you can use the
> same port for encrypted and also for unencrypted connections. The client
> can now decide on the IP address which kind of connection
> (encrypted/unencryped) it wants to use.
>
> I hope, this will help you.
>
> Cheers
> Eberhard
>
>
> Nagaraj Gidde schrieb am Freitag, 29. Oktober 2021 um 09:00:42 UTC+2:
>
>> Hello All,
>>
>> We have a complicated situation where need to support a secure and
>> insecure channel on single port for grpc server for backward compatibility.
>>
>> Is it possible to have such config. Any thoughts on how to achieve will
>> be highly appreciated.
>>
>> Thanks & Regards,
>> Nag.
>>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/6f713bd3-4e84-4341-96d8-edf913270b41n%40googlegroups.com.
