How best to implement registration system on unkonwn environments?

26 views
Skip to first unread message

groo...@gmail.com

unread,
Oct 9, 2018, 7:26:03 PM10/9/18
to grpc.io
Hey guys,

We have a desktop application that is designed to integrate with a number of other programs. We have plugins for these programs, and we need them to _discover_ our desktop software. Right now our software is an executable and most plugins are .net assemblies (all plugins are in a GRPC friendly environment) but in the near future I'm hoping to have a windows service/linux daemon, which should mean its always running. But, of course, I need to handle service interruptions. Further, I cannot hard-code to any port because I wont know what ports are available at start time.

Does anybody know of a simple way to negotiate connection strings for grpc clients and servers?

I'm thinking about using statically known file paths in combination with registry values and/or environment values to create a kind of queue file, where we can use the file to bootstrap into sockets.

What I realize I'm really after is an IPC event bus with gRPC, and what I'd really like to do is make somebody else solve the registration problem.

Failing that, can I specify "Files" as a type for the protobuf "Connection" object? That would also let me differ some nasty gotcha's --particularly from Java callers--, and hopefully make for a reasonably elegant grpc document.

Any suggestions?

Thanks!

Benjamin Krämer

unread,
Oct 10, 2018, 7:07:30 AM10/10/18
to grpc.io
If I understood that correctly, you want to use gRPC (server + client) only on the same machine? You can always use ports in the range 1024 to 49151 since they are not reserved by the system and also not dynamically assigned. Do you know what machines this will run on? I usually just have the port configurable but fixed. Other than that, you surely can use a file that is written when the port was dynamically assigned after the server was started. But this will lead to problems when the server restarts and the client still thinks the old port is valid. As long as you do not use any functionallity like GRPCLB (load balancer), channels default to trying to reestablish the connection.
Reply all
Reply to author
Forward
0 new messages