llvm dev - Dec 2019 - Network RPCs in LLVM projects

On Fri, Dec 13, 2019 at 2:12 PM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Dec 12, 2019, at 5:58 AM, Sam McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Short version: clangd would like to be able to build a client+server that
> can make RPCs across the internet. An RPC system isn't a trivial
dependency
> and rolling our own from scratch isn't appealing.
> Have other projects had a need for this? Any advice on how to approach
> such dependencies?
>
> --
>
> Longer: clangd (a language server, like an IDE backend) builds an index of
> the project you're working on in order to answer queries (go to
definition,
> code completion...). This takes *lots* of CPU-time to build, and RAM to
> serve.
> For large codebases with many developers, sharing an index across users
>
<https://llvm.discourse.group/t/sharing-indexes-for-multiple-users/202>
> is a better approach - you spend the CPU in one place, you spend the RAM in
> a few places, and an RPC is fast enough even for code completion. We have
> experience with this approach inside Google.
>
> We'd like to build this index server upstream (just a shell around
> clangd's current index code) and put the client in clangd. For
open-source
> projects, I imagine the server being publicly accessible over the internet.
> This means we care about
>  - latency (this is interactive, every 10ms counts)
>  - security
>  - proxy traversal, probably
>  - sensible behavior under load
>  - auth is probably nice-to-have
>
> I don't think this is something we want to build from scratch, I hear
> portable networking is hard :-)
>
>
> It really isn't that bad. Just as a note, LLDB does have portable
socket
> communication already, so it could be a refactor and reuse exercise rather
> than building from scratch.
>
It sounds as if the clangd index server is supposed to work across the open
internet, which effectively means it needs to speak HTTPS. That's not
really something that you can just write.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191213/e6710cb9/attachment.html>

> On Dec 13, 2019, at 2:09 PM, James Y Knight <jyknight at google.com>
wrote:
> 
> 
> 
> On Fri, Dec 13, 2019 at 2:12 PM Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> 
>> On Dec 12, 2019, at 5:58 AM, Sam McCall via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Short version: clangd would like to be able to build a client+server
that can make RPCs across the internet. An RPC system isn't a trivial
dependency and rolling our own from scratch isn't appealing.
>> Have other projects had a need for this? Any advice on how to approach
such dependencies?
>> 
>> --
>> 
>> Longer: clangd (a language server, like an IDE backend) builds an index
of the project you're working on in order to answer queries (go to
definition, code completion...). This takes *lots* of CPU-time to build, and RAM
to serve.
>> For large codebases with many developers, sharing an index across users
<https://llvm.discourse.group/t/sharing-indexes-for-multiple-users/202> is
a better approach - you spend the CPU in one place, you spend the RAM in a few
places, and an RPC is fast enough even for code completion. We have experience
with this approach inside Google.
>> 
>> We'd like to build this index server upstream (just a shell around
clangd's current index code) and put the client in clangd. For open-source
projects, I imagine the server being publicly accessible over the internet.
>> This means we care about
>>  - latency (this is interactive, every 10ms counts)
>>  - security
>>  - proxy traversal, probably
>>  - sensible behavior under load
>>  - auth is probably nice-to-have
>> 
>> I don't think this is something we want to build from scratch, I
hear portable networking is hard :-)
> 
> It really isn't that bad. Just as a note, LLDB does have portable
socket communication already, so it could be a refactor and reuse exercise
rather than building from scratch.
> 
> It sounds as if the clangd index server is supposed to work across the open
internet, which effectively means it needs to speak HTTPS. That's not really
something that you can just write.
I think speaking over the open internet means they need TLS, which OpenSSL
should be a sufficient and reasonable dependency for. Are they really talking
HTTP? If so, I would have expected different suggestions for open source project
dependencies because I'm not sure Thrift builds in HTTP support (gRPC does).

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191213/42b355ff/attachment.html>

On Fri, Dec 13, 2019 at 2:07 PM Chris Bieneman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Dec 13, 2019, at 2:09 PM, James Y Knight <jyknight at google.com>
wrote:
>
>
>
> On Fri, Dec 13, 2019 at 2:12 PM Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>>
>>
>> On Dec 12, 2019, at 5:58 AM, Sam McCall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Short version: clangd would like to be able to build a client+server
that can make RPCs across the internet. An RPC system isn't a trivial
dependency and rolling our own from scratch isn't appealing.
>> Have other projects had a need for this? Any advice on how to approach
such dependencies?
>>
>> --
>>
>> Longer: clangd (a language server, like an IDE backend) builds an index
of the project you're working on in order to answer queries (go to
definition, code completion...). This takes *lots* of CPU-time to build, and RAM
to serve.
>> For large codebases with many developers, sharing an index across users
is a better approach - you spend the CPU in one place, you spend the RAM in a
few places, and an RPC is fast enough even for code completion. We have
experience with this approach inside Google.
>>
>> We'd like to build this index server upstream (just a shell around
clangd's current index code) and put the client in clangd. For open-source
projects, I imagine the server being publicly accessible over the internet.
>> This means we care about
>>  - latency (this is interactive, every 10ms counts)
>>  - security
>>  - proxy traversal, probably
>>  - sensible behavior under load
>>  - auth is probably nice-to-have
>>
>> I don't think this is something we want to build from scratch, I
hear portable networking is hard :-)
>>
>>
>> It really isn't that bad. Just as a note, LLDB does have portable
socket communication already, so it could be a refactor and reuse exercise
rather than building from scratch.
>
>
> It sounds as if the clangd index server is supposed to work across the open
internet, which effectively means it needs to speak HTTPS. That's not really
something that you can just write.
>
>
> I think speaking over the open internet means they need TLS, which OpenSSL
should be a sufficient and reasonable dependency for. Are they really talking
HTTP? If so, I would have expected different suggestions for open source project
dependencies because I'm not sure Thrift builds in HTTP support (gRPC does).
Just commenting as a distant observer interested in the high level
topic of serialization and RPCs: Does the C++ necessarily have to talk
HTTP? For example, if the system can be structured in such a way that
a C++ engine can talk to a local socket, then one can build a HTTP
capable server in Python to communicate with the C++ engine over the
local socket. If structured this way, the server code need not stay in
the LLVM tree. And, the users are free to build the real server in a
manner that suits them.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev