-
Notifications
You must be signed in to change notification settings - Fork 336
GraphEngine.Client #346
Not a question here - I am a heavy user of GraphEngine.Client library as it is integral to much of what we are able to do. Do you plan on updating the library? In my forked instance, I have continued to use it and extend its capability set. I wonder if others are using the GraphEngine.Client library.
All reactions
Replies: 3 comments 4 replies
All reactions
gRPC could also provide streaming which you required in #348.
All reactions
Yes - gRPC would help with security and securing APIs. I'm playing around now with securing the TCP connection and using licensing technology on the API. Either way, GE needs improvement in this area to gain mainstream adoption and usage. I like gRPC!
All reactions
gRPC is a fantastic addition to GE, and we have been playing around with such integration for about a year now. Given that GE is so versatile, it is reasonable that it supports a wide verify of network protocols. I am working on another project where we are using GE as the primary Graph store for BlockChain as that is a TCP/RPC environment. Please note that I am already streaming over Rx and TCP, and it does not look like you explored GE LIKQ yet. That will blow you away more. Watch the LIKQ demonstration video - Killer!
All reactions
Watch the LIKQ demonstration video - Killer!
Would you be so kind and provide a link to the video? I can't seem to find it. Also, if you have links to other videos/resources not mentioned on https://www.graphengine.io/ I'll gladly accept them 😃
All reactions
LIKQ Demonstration Video:
All reactions
= Module GraphEngine.Client =
Provides client-side communication instance. In a GraphEngine application, a client is by-default not a communication instance -- for that it does not possess message handling capabilities. GraphEngine.Client extends both the client and the server to support client-side message handling through a single messaging endpoint, while preserving the ability to access the whole memory cloud.
When a client communication instance starts, it connects to the server with a customizable messaging endpoint. The endpoint should implement the interface IMessagePassingEndpoint, but is not limited to using native Trinity protocol. Therefore we could implement the interface with any messaging transport, e.g. WCF, gRPC etc. Once the endpoint establishes connection, the client registers itself at the destination server with a randomly generated cookie. The server keeps track of the connected clients, and assigns a TTL value to each client. The server does not initiate new connections to the clients, but rather, responds to client-side polling. New client-going messages are first queued at the server, and piggybacked during polling. This allows a client to send asynchronous messages, without being blocked by a single request/response pair on the endpoint.
This module also implements MemoryCloud for both client and server. The server side uses HostedMemoryCloud: FixedMemoryCloud and provides aforementioned client-registration services. The client side uses ClientMemoryCloud: MemoryCloud, which takes a single message passing endpoint (rather than connecting to every remote storage in the cluster), and send all messages as redirected messages, and all key-value store operations as custom remote calls, which are handled in TrinityClientModule.