Re: good RPC framework for D?

2017-08-09 Thread jasonsalex via Digitalmars-d

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:

Is there a good RPC framework for D?

requirements:
* efficient (no json/xml)
* supports at least sending/receiving raw bytes

I tried msgpack-rpc but it seems abandonned (last commit 2 y 
ago) and this issue makes it unusable: 
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for 
messages of length >= 4090 bytes.


I would love to have a GRPC work with D but couldn't find a 
package for it.


Is there at least a reliable solution that sends raw bytes ? 
than I can for eg wrap protobufs or other serialized formats 
via serialization/deserialization.


Additional requirements: supports streaming data (either input 
or

output or both), and timeouts.



KissRPC For Flatbuffer : https://github.com/huntlabs/kiss-rpc

kiss-rpc-flatbuffer features:

Lightweight and easy to use. There are two ways to support IDL 
and manually write protocols. Analog function call, more in line 
with the RPC remote call logic, simple, transparent.


Easy to change, easy to use, existing code can be used directly

The data format supports downward compatibility and uses the 
flatbuffer protocol, with better compatibility and faster speed.


Support multi valued return feature, support timeout mechanism, 
analog grpc, thrift, Dubbo fast several times or even dozens of 
times.


Support snappy compression algorithm, compression speed, superior 
performance.


Support pipeline data compression, dynamic data compression, 
request data compression, flexible use of a wide range of 
scenarios.


Re: good RPC framework for D?

2017-06-06 Thread Ola Fosheim Grøstad via Digitalmars-d

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:
Is there at least a reliable solution that sends raw bytes ? 
than I can for eg wrap protobufs or other serialized formats 
via serialization/deserialization.


Additional requirements: supports streaming data (either input 
or

output or both), and timeouts.


Sounds like you want to use a raw TCP/IP connection...


Re: good RPC framework for D?

2017-06-05 Thread Laeeth Isharc via Digitalmars-d

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:

Is there a good RPC framework for D?

requirements:
* efficient (no json/xml)
* supports at least sending/receiving raw bytes

I tried msgpack-rpc but it seems abandonned (last commit 2 y 
ago) and this issue makes it unusable: 
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for 
messages of length >= 4090 bytes.


I would love to have a GRPC work with D but couldn't find a 
package for it.


Is there at least a reliable solution that sends raw bytes ? 
than I can for eg wrap protobufs or other serialized formats 
via serialization/deserialization.


Additional requirements: supports streaming data (either input 
or

output or both), and timeouts.


I am working right now on wrapping grpc, but it's a bit of work 
and I have lots of other things to do and can't be sure when or 
if I will finish.  The C API is not that bad once you understand 
what if is doing.  And see dprotobuf.





Re: good RPC framework for D?

2017-06-05 Thread Neia Neutuladh via Digitalmars-d

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:

Is there a good RPC framework for D?


Last time I needed one, I used Thrift. D support in Thrift is 
maintained upstream. Unfortunately, the version available in dub 
is really old. Also unfortunately, it's std.socket only -- no 
vibe.d.


https://thrift.apache.org/docs/features
https://github.com/apache/thrift/tree/master/lib/d


requirements:
* efficient (no json/xml)


Thrift uses a binary format relatively similar to protocol 
buffers.



* supports at least sending/receiving raw bytes


Thrift supports a `binary` data type representing a byte array.

Additional requirements: supports streaming data (either input 
or output or both)


I'm not sure what you mean by "streaming data", precisely, but 
Thrift supports multiple RPCs per  connection. This alone made a 
huge difference in my testing: a Thrift server on an AWS t2.micro 
 managed 2400 requests per second across ten clients, while HTTP 
handlers returning a fixed string only managed 75.



and timeouts.


Definitely supports timeouts.