Apache Thrift is a lightweight, language-independent software stack for point-to-point RPC implementation

Apache Thrift

Introduction

Thrift is a lightweight, language-independent software stack for point-to-point RPC implementation. Thrift provides clean abstractions and implementations for data transport, data serialization, and application level processing. The code generation system takes a simple definition language as input and generates code across programming languages that uses the abstracted stack to build interoperable RPC clients and servers.

Apache Thrift Layered Architecture

Thrift makes it easy for programs written in different programming languages to share data and call remote procedures. With support for 28 programming languages, chances are Thrift supports the languages that you currently use.

Thrift is specifically designed to support non-atomic version changes across client and server code. This allows you to upgrade your server while still being able to service older clients; or have newer clients issue requests to older servers. An excellent community-provided write-up about thrift and compatibility when versioning an API can be found in the Thrift Missing Guide.

For more details on Thrift's design and implementation, see the Thrift whitepaper included in this distribution, or at the README.md file in your particular subdirectory of interest.

Status

Branch Travis Appveyor Coverity Scan codecov.io Website
master Build Status Build status Coverity Scan Build Status Website
0.14.0 Build Status

Releases

Thrift does not maintain a specific release calendar at this time.

We strive to release twice yearly. Download the current release.

License

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Project Hierarchy

thrift/

compiler/

Contains the Thrift compiler, implemented in C++.

lib/

Contains the Thrift software library implementation, subdivided by
language of implementation.

cpp/
go/
java/
php/
py/
rb/
...

test/

Contains sample Thrift files and test code across the target programming
languages.

tutorial/

Contains a basic tutorial that will teach you how to develop software
using Thrift.

Development

To build the same way Travis CI builds the project you should use docker. We have comprehensive building instructions for docker.

Requirements

See http://thrift.apache.org/docs/install for a list of build requirements (may be stale). Alternatively, see the docker build environments for a list of prerequisites.

Resources

More information about Thrift can be obtained on the Thrift webpage at:

 http://thrift.apache.org

Acknowledgments

Thrift was inspired by pillar, a lightweight RPC tool written by Adam D'Angelo, and also by Google's protocol buffers.

Installation

If you are building from the first time out of the source repository, you will need to generate the configure scripts. (This is not necessary if you downloaded a tarball.) From the top directory, do:

./bootstrap.sh

Once the configure scripts are generated, thrift can be configured. From the top directory, do:

./configure

You may need to specify the location of the boost files explicitly. If you installed boost in /usr/local, you would run configure as follows:

./configure --with-boost=/usr/local

Note that by default the thrift C++ library is typically built with debugging symbols included. If you want to customize these options you should use the CXXFLAGS option in configure, as such:

./configure CXXFLAGS='-g -O2'
./configure CFLAGS='-g -O2'
./configure CPPFLAGS='-DDEBUG_MY_FEATURE'

To enable gcov required options -fprofile-arcs -ftest-coverage enable them:

./configure  --enable-coverage

Run ./configure --help to see other configuration options

Please be aware that the Python library will ignore the --prefix option and just install wherever Python's distutils puts it (usually along the lines of /usr/lib/pythonX.Y/site-packages/). If you need to control where the Python modules are installed, set the PY_PREFIX variable. (DESTDIR is respected for Python and C++.)

Make thrift:

make

From the top directory, become superuser and do:

make install

Uninstall thrift:

make uninstall

Note that some language packages must be installed manually using build tools better suited to those languages (at the time of this writing, this applies to Java, Ruby, PHP).

Look for the README.md file in the lib// folder for more details on the installation of each language library package.

Package Managers

Apache Thrift is available via a number of package managers, a list which is is steadily growing. A more detailed overview can be found at the Apache Thrift web site under "Libraries" and/or in the respective READMEs for each language under /lib

Testing

There are a large number of client library tests that can all be run from the top-level directory.

make -k check

This will make all of the libraries (as necessary), and run through the unit tests defined in each of the client libraries. If a single language fails, the make check will continue on and provide a synopsis at the end.

To run the cross-language test suite, please run:

make cross

This will run a set of tests that use different language clients and servers.

Owner
The Apache Software Foundation
The Apache Software Foundation
Comments
  • THRIFT-5073: Optional handler interceptor for processor

    THRIFT-5073: Optional handler interceptor for processor

    Hi.

    Thank for this great project. But I think we can introduce some improvements which will be are useful for other developers.

    Inspired by https://github.com/grpc/grpc-go/blob/master/examples/features/interceptor/server/main.go.

    Interceptors give opportunities for:

    Logging input request and response We can log panic situation and return TApplicationException to client instead of EOF. We can intercept request and do stuff like some validation, etc. Usage example: https://gist.github.com/voodoo-dn/6af6cf54b8145cc3d4d87d888c4bf907

  • THRIFT-4329: Implement multiplexed processor that matches CPP and Java. Tested aga…

    THRIFT-4329: Implement multiplexed processor that matches CPP and Java. Tested aga…

    Implement multiplexed processor that matches CPP and Java. Tested against Java
    Missing Test suite
    Implement stored message protocol that adds the possibility of reading a header of a message and then process it
    

    I don't remember how to do cross tests from protocols. I want to test Java and C multiplexors against a C server. I did in my test units but Don't find the way here. I did it before so I will check.

    For now it's safe to merge this.

  • Fix abstract unix socket name

    Fix abstract unix socket name

    For the abstract unix socket address type, the string in the 'sun_path' field of the 'sockaddr_un struct', is a not null-terminated string (see unix(7)).

    Fix the lentgh calculation of the 'sun_path' field to don't add the termination null byte.

  • THRIFT-5093: lib: cpp: test: clarify effect of MemoryPolicy on TMemoryBuffer

    THRIFT-5093: lib: cpp: test: clarify effect of MemoryPolicy on TMemoryBuffer

    My main use case with the original code change was that I wanted to be able to call resetBuffer() on OBSERVE buffers and reuse the contents for test cases over and over. While the default resetBuffer() cannot be used for that purpose, the same result can be achieved by calling resetBuffer(ro_mem, ro_mem_size, OBSERVE) as well, so the workaround is fairly trivial.

    While the former implementation would be more convenient in some cases, it makes more sense to have consistent behaviour for all resetBuffer() implementations.

    Added test cases to clarify the effect of MemoryPolicy on TMemoryBuffer behaviour.

    • [x] Did you create an Apache Jira ticket? (not required for trivial changes)
    • [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
    • [x] Did you squash your changes to a single commit? (not required, but preferred)
    • [x] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
    • [ ] If your change does not involve any code, add [skip ci] at the end of your pull request to free up build resources.
  • THRIFT-2945 Add Rust support

    THRIFT-2945 Add Rust support

    This is a PR to add Rust support to Thrift. It is based on today's master, and I've verified that Rust server/client successfully communicates with all cross-platform clients and servers (*). I would be happy to accept and incorporate feedback!

    Not implemented:

    • Struct/union constants: Honestly, this looks like it's "not possible" (tm)
    • Multiplexed processor

    I will be continuing to add documentation, comments and clean up the code in both the C++ generator as well as the Rust client library.

    (*) With exception of:

    1. D: no D compiler installed
    2. Lua: need to find out how to use .dylib when using Lua libs
    3. Dart: weird problem with pubspec requiring 1.0.0 instead of 1.0.0-dev
  • THRIFT-3773 Swift 3 Native Library

    THRIFT-3773 Swift 3 Native Library

    Here is my implementation of the Thrift library for Swift 3.0, pure swift.
    There is no Objective-C requirement here. For implementation and design details, please refer to comments here: https://issues.apache.org/jira/browse/THRIFT-3773?jql=text%20~%20%22swift%22 And to the README here: https://github.com/apocolipse/thrift/tree/master/lib/swift

  • THRIFT-4434. Update .NET Core components, add tests for .Net Core library and .Net Core compiler, fix bugs and build process

    THRIFT-4434. Update .NET Core components, add tests for .Net Core library and .Net Core compiler, fix bugs and build process

    This pull request should:

    • highly improve the current version of .Net Core library and .Net Core compiler and quality of code
    • improve and simplify build process
    • improve documentation related to .Net Core library and compiler
    • fix found bugs (some of bugs can be clarified like major - they are related to porting of protocols from Java version and can be present in C# library)
    • add important unit tests for .Net Core library and .Net Core compiler
    • add possibility to easy add unit tests for compiler for other languages
  • [THRIFT-82] Add Common Lisp support

    [THRIFT-82] Add Common Lisp support

    There's framed and buffered socket transport, binary protocol, multiplex, simple server, cross-tests, self-tests, tutorial, CL library, CL code generator. Only SBCL is supported for now.

  • Thrift 2905 &  - Modern Objective-C & Swift Support

    Thrift 2905 & - Modern Objective-C & Swift Support

    This pull request is really just to start a conversation about how to move forward with the changes I've made to the Thrift Cocoa library and generator.

    The nature of the changes are that they are big & a bit destructive. Unfortunately there wasn't much getting around that. Hopefully working with the community we can agree on the best way to integrate these changes. Maybe just as another "language" binding instead of replacing the current "cocoa".

    Goals

    • Modernize generated code
    • Increase asynchronous support (both blocks and promises)
    • Remove use of deprecated classes & paradigms (e.g NSException, NSURLConnection)
    • Generate Swift client & server code

    Major Changes

    • Addes Swift code generator

    • Use NSError based error & exception handling
    • Optionally generate PromiseKit methods in the asynchronous clients
    • Change asynchronous clients to be fully multi-thread safe
    • Added THTTPSessionTransport, asynchronous HTTP transport that works with NSURLSession
    • Use NS_ENUM enumerations (with standard format)
    • Use immutable collection types (e.g. NSArray) in service methods
    • Struct fields & their "set" flags now use properties exclusively
    • Helper classes now include the service name to fix duplicate naming issue when two services has the same method name
    • NSCopying is implemented correctly for structs
    • Simple constants are now "exported" public variables
    • Optionally use CocoaPods style imports with Podspec (e.g. <Thrift/File.h>)
    • Removed instance variables from public headers
    • Remove retain/release stubs
    • Remove all deallocs

    Why?

    We made some very large changes. Here's why...

    NSException to NSError

    The use of NSException has been very problematic for us. Aside from the direction of Apple, which is to use exceptions for "fatal errors" only, it comes with a host of issues. First, Clang still produces incorrect code in many cases when using exceptions. Take this code for example...

    executeBlockAndReturnValue(^{
      @try {
        return value;
      }
      @catch(NSException *e) {
      }
      // should be a return statement on this branch, Clang produces no error/warning
    });
    

    Clang should produce an error but doesn't. This is only a nuisance though, much worse are the ARC failures we've found when catching exceptions up the stack. Secondly, Swift has no support for exceptions (and with Swift 2 we've seen it won't ever use NSException).

    It's for these reasons we changed the the Cocoa library to use NSError, all of the generated (synchronous) methods now follow the Apple guidelines and return a BOOL or object pointer with a last error parameter of type NSError**; return values of NO or nil mean the error parameter is populated and the call failed (or and exception was thrown from the server). These changes have been made throughout the generated and library code.

    Client Method Mapping

    • Methods returning basic types are mapped to NSNumber/NSValue - nil reports call failure/exception
    • Methods returning VOID are mapped to return BOOL - NO reports call failure/exception
    • Methods returning Struct/String/Binary return the object value as normal - nil reports call failure/exception

    NSError & Swift 2

    These changes conveniently take the form of Swift 2's error handling system. This means that protocols and transports can be used from and written in Swift and will be compatible with the current & future directions of Swift.

    ARC Only

    ARC is here to stay; Apple deprecated everything else a few years ago. All code related to maintaining backwards compatibly with non-ARC mode has been removed.

    Mutl-Threaded Asynchronous Transports

    The current implementations means that clients cannot be used in different threads. This means the user is left to synchronize access to them or, as in our case, build a client per thread to ensure parallelism.

    Our changes have reengineered the way asynchronous works. Now, asynchronous clients accept only protocol and async-transport factories. Each call allocates a new transport and protocol binds them before use. This provides the best options for parallelism with a fairly small overhead.

    A note on performance... the alternative approaches, which we used in the past, required thread local storage inside the transport which meant an NSDictionary lookup (i.e. threadDictionary) for each read/write/flush. The new approach only requires 2 simple object allocations. Much improved.

    NSURLSession (NSURLConnection is now deprecated)

    The new THTTPSessionTransport replaces the old THTTPClient. It's both asynchronous and uses the new NSURLSession classes for conformance in the new iOS/OSX versions.

    NS_ENUM & Swift

    The generated code now generates properly formatted enumerations using the NS_ENUM macro & no underscores. This is to ensure they work with code completion in objective-c and are imported into Swift with the best possible syntax.

  • make optional fields work in Golang

    make optional fields work in Golang

    Hi Jens, This is a [hopefully] minimal fix for https://issues.apache.org/jira/browse/THRIFT-2232.

    For anyone else who's looking at this, the goal is to decouple the IsSet...() methods from the values of the fields they correspond to.

    For example, prior to this change, an optional int with a value of 0 was considered absent per IsSetXYZ(). This is clearly broken, since 0 is often a valid value for a field.

    The approach taken -- per the discussion on jira -- is to use pointers to fields within the generated Go structs.

    A few notes about this approach:

    • the existing code already used pointers for struct-valued fields, so now those are special-cased.
    • since one cannot take the address of a temporary in Go, we must create some temporaries just to get pointers in certain situations.
    • we did get to remove a big block of IsSet()-generation code, which is a nice bonus.

    The new code works great for my company's project, though we don't use every thrift feature available. I generated all of the examples and tried to go build them; all of the example files that generated valid Go code prior to this change continue to do so after this change, though I don't see a full test suite to validate beyond that.

    Thanks for your time and attention! Ben

  • THRIFT-5495: close client when shutdown server in go lib

    THRIFT-5495: close client when shutdown server in go lib

    Client: [go]

    If there is client connection and no data is send,we will encounter hang druing server stop: 1>If transport factory conf with socket timeout,we will hang until the deadline of the socket

    2>If transport factory conf without socket timeout,we will hang forever

    Stack As below: goroutine 140800 [IO wait, 2706 minutes]: internal/poll.runtime_pollWait(0x7fbf804fb100, 0x72) runtime/netpoll.go:234 +0x89 internal/poll.(*pollDesc).wait(0xc009087700, 0xc008196000, 0x0) internal/poll/fd_poll_runtime.go:84 +0x32 internal/poll.(*pollDesc).waitRead(...) internal/poll/fd_poll_runtime.go:89 internal/poll.(*FD).Read(0xc009087700, {0xc008196000, 0x10000, 0x10000}) internal/poll/fd_unix.go:167 +0x25a net.(*netFD).Read(0xc009087700, {0xc008196000, 0x0, 0xc0061089b8}) net/fd_posix.go:56 +0x29 net.(*conn).Read(0xc007c98038, {0xc008196000, 0x0, 0xc006108978}) net/net.go:183 +0x45 github.com/apache/thrift/lib/go/thrift.(*socketConn).Read(0x246aae0, {0xc008196000, 0xc0058b4ed0, 0x246aae0}) github.com/apache/[email protected]/lib/go/thrift/socket_conn.go:101 +0x44 github.com/apache/thrift/lib/go/thrift.(*TSocket).Read(0xc003555460, {0xc008196000, 0x10000, 0x10000}) github.com/apache/[email protected]/lib/go/thrift/socket.go:221 +0x67 bufio.(*Reader).Read(0xc005657320, {0xc001da1000, 0x1000, 0x203000}) bufio/bufio.go:227 +0x1b4 github.com/apache/thrift/lib/go/thrift.(*TBufferedTransport).Read(0xc0035554a0, {0xc001da1000, 0x431e10, 0x64}) github.com/apache/[email protected]/lib/go/thrift/buffered_transport.go:67 +0x45 bufio.(*Reader).Read(0xc005657380, {0xc0090877f0, 0x4, 0x4b5bac0}) bufio/bufio.go:227 +0x1b4 io.ReadAtLeast({0x30c0520, 0xc005657380}, {0xc0090877f0, 0x4, 0x4}, 0x4) io/io.go:328 +0x9a io.ReadFull(...) io/io.go:347 github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).readFrame(0xc009087780) github.com/apache/[email protected]/lib/go/thrift/framed_transport.go:199 +0x3c github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).Read(0xc009087780, {0xc0090877f0, 0x1, 0x4}) github.com/apache/[email protected]/lib/go/thrift/framed_transport.go:148 +0x130 github.com/apache/thrift/lib/go/thrift.(*TFramedTransport).ReadByte(0xc009087780) github.com/apache/[email protected]/lib/go/thrift/framed_transport.go:157 +0x2e github.com/apache/thrift/lib/go/thrift.(*TCompactProtocol).readByteDirect(...) github.com/apache/[email protected]/lib/go/thrift/compact_protocol.go:766 github.com/apache/thrift/lib/go/thrift.(*TCompactProtocol).ReadMessageBegin(0xc008765040, {0x311a118, 0xc00319ede0}) github.com/apache/[email protected]/lib/go/thrift/compact_protocol.go:367 +0x62

  • THRIFT-5644: java to use jdk 17

    THRIFT-5644: java to use jdk 17

    java to use jdk 17, this is a second try after #2662

    • [x] Did you create an Apache Jira ticket? (not required for trivial changes)
    • [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
    • [x] Did you squash your changes to a single commit? (not required, but preferred)
    • [x] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
    • [x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.
  • THRIFT-5633: [build infra] add ubuntu jammy in build infra

    THRIFT-5633: [build infra] add ubuntu jammy in build infra

    add ubuntu jammy in build infra

    • [x] Did you create an Apache Jira ticket? (not required for trivial changes)
    • [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
    • [x] Did you squash your changes to a single commit? (not required, but preferred)
    • [x] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
    • [x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.
  • lib: cpp: thrift: include functional in TServerFramework

    lib: cpp: thrift: include functional in TServerFramework

    Use of std::placeholders::_1 requires <functional>.

    • [ ] Did you create an Apache Jira ticket? (not required for trivial changes) No
    • [ ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? No
    • [ ] Did you squash your changes to a single commit? (not required, but preferred) Yes
    • [ ] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking- Change"? Yes
  • lib: cpp: TProtocol: support zephyr byteorder

    lib: cpp: TProtocol: support zephyr byteorder

    Zephyr's byteorder is defined in <zephyr/sys/byteorder.h>. However, the bswap_xx macros are also defined there. They need to be #undefd first when building for big-endian architectures, since the Thrift byteorder macros are no-ops for little-endian architectures.

    • [ ] Did you create an Apache Jira ticket? (not required for trivial changes) No
    • [ ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? No
    • [ ] Did you squash your changes to a single commit? (not required, but preferred) Yes
    • [ ] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"? Yes
  • lib: cpp: TOutput: add zephyr-specific strerror_s implementation

    lib: cpp: TOutput: add zephyr-specific strerror_s implementation

    In Zephyr, optimize TOutput::strerror_s to minimize (stack) space. The string error table is in ROM in any case, so string values will not be overwritten (if they happen to be compiled-in).

    • [ ] Did you create an Apache Jira ticket? (not required for trivial changes) No
    • [ ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? No
    • [ ] Did you squash your changes to a single commit? (not required, but preferred) Yes
    • [ ] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"? Yes
    • [ ] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.
  • GitHub cmake workflow to build libraries as well [skip ci]

    GitHub cmake workflow to build libraries as well [skip ci]

    • [x] Did you create an Apache Jira ticket? (not required for trivial changes)
    • [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
    • [x] Did you squash your changes to a single commit? (not required, but preferred)
    • [x] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
    • [x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.
Packio - An asynchronous msgpack-RPC and JSON-RPC library built on top of Boost.Asio.

Header-only | JSON-RPC | msgpack-RPC | asio | coroutines This library requires C++17 and is designed as an extension to boost.asio. It will let you bu

Aug 31, 2022
RPC++ is a tool for Discord RPC (Rich Presence) to let your friends know about your Linux system
RPC++ is a tool for Discord RPC (Rich Presence) to let your friends know about your Linux system

RPC++ RPC++ is a tool for Discord RPC (Rich Presence) to let your friends know about your Linux system Installing requirements Arch based systems pacm

Jul 6, 2022
The Apache Kafka C/C++ library

librdkafka - the Apache Kafka C/C++ client library Copyright (c) 2012-2020, Magnus Edenhill. https://github.com/edenhill/librdkafka librdkafka is a C

Sep 27, 2022
Bringing rustls into the Apache server.

mod_tls - memory safety for TLS in Apache This repository contains mod_tls, a module for Apache httpd that uses rustls to provide a memory safe TLS im

Feb 8, 2022
Mirror of Apache C++ Standard Library

$Id$ Apache C++ Standard Library (STDCXX) 5.0.0 ------------------------------------------ 0 Index -------- Inde

Aug 2, 2022
Side-channel file transfer between independent VM executed on the same physical host
Side-channel file transfer between independent VM executed on the same physical host

Inter-process or cross-VM data exchange via CPU load modulation What is this I made this PoC as a visual aid for an online discussion about M1RACLES -

Jul 26, 2022
Sep 27, 2022
To have platform independent network interfaces over usb which is working with Linux, Windows, Mac OS ect.
To have platform independent network interfaces over usb which is working with Linux, Windows, Mac OS ect.

To have platform independent network interfaces over usb which is working with Linux, Windows, Mac OS ect. called RNDIS. This project is a RNDIS demo, which addtionally implements a http server. It runs out of the box on a stm32f411 BlackPill board. My RNDIS library with an empty template for the second interface (which can ba UART, CAN, ETH or like in this demo a tcp/ip stack) can be found under following link: https://github.com/RDMsmartnetworks/STM32_HAL_RNDIS

Sep 21, 2022
A very simple, fast, multithreaded, platform independent HTTP and HTTPS server and client library implemented using C++11 and Boost.Asio.

A very simple, fast, multithreaded, platform independent HTTP and HTTPS server and client library implemented using C++11 and Boost.Asio. Created to be an easy way to make REST resources available from C++ applications.

Sep 28, 2022
LAppS - Lua Application Server for micro-services with default communication over WebSockets. The fastest and most vertically scalable WebSockets server implementation ever. Low latency C++ <-> Lua stack roundtrip.

LAppS - Lua Application Server This is an attempt to provide very easy to use Lua Application Server working over WebSockets protocol (RFC 6455). LApp

Apr 25, 2022
A Tcp/Ip stack implementation on top of Solarflare ef_vi, and a C++ headers only framework for tcp multiplexing client/server.

Efvitcp Efvitcp is a tcp library using Solarflare ef_vi interface on linux, and also a tcp multiplexing framework for both C++ client and server progr

Sep 27, 2022
Sep 29, 2022
🚀 Discord RPC Blocker for Lunar Client
🚀 Discord RPC Blocker for Lunar Client

?? Soyuz Soyuz has one simple purpose; listen for incoming Discord RPC requests from Lunar Client and block them! Limitations Windows only Soon to com

Aug 3, 2022
C++ framework for json-rpc (json remote procedure call)
C++ framework for json-rpc (json remote procedure call)

I am currently working on a new C++17 implementation -> json-rpc-cxx. Master Develop | libjson-rpc-cpp This framework provides cross platform JSON-RPC

Sep 18, 2022
modern C++(C++11), simple, easy to use rpc framework

modern C++(C++11), simple, easy to use rpc framework

Sep 30, 2022
gRPC - An RPC library and framework Baind Unity 3D Project

Unity 3D Compose for Desktop and Android, a modern UI framework for C ++ , C# that makes building performant and beautiful user interfaces easy and enjoyable.

May 19, 2022
Gromox - Groupware server backend with MAPI/HTTP, RPC/HTTP, IMAP, POP3 and PHP-MAPI support for grommunio

Gromox is the central groupware server component of grommunio. It is capable of serving as a replacement for Microsoft Exchange and compatibles. Conne

Sep 23, 2022
Fastest RPC in the west
Fastest RPC in the west

smf - the fastest RPC in the West We're looking for a new maintainer for the SMF project. As I have little time to keep up with issues. Please let me

Sep 27, 2022
mTCP: A Highly Scalable User-level TCP Stack for Multicore Systems

README mTCP is a highly scalable user-level TCP stack for multicore systems. mTCP source code is distributed under the Modified BSD License. For more

Sep 22, 2022