messagepack-rpc alternatives and similar packages
Based on the "Networking" category.
Alternatively, view messagepack-rpc alternatives based on common mentions on social networks and blogs.
-
snap-core
Core type definitions (Snap monad, HTTP types, etc) and utilities for web handlers. -
websockets
A Haskell library for creating WebSocket-capable servers -
call-haskell-from-anything
Call Haskell functions from any programming language via serialization and dynamic libraries -
snap-server
A fast HTTP server library, which runs Snap web handlers. -
PortFusion
Haskell-powered cross-platform transport-layer distributed reverse / forward proxy & tunneling solution – currently available for all TCP protocols (RDP, VNC, HTTP(S), SSH, ...). -
io-streams
Simple, composable, and easy-to-use stream I/O for Haskell -
network-transport-zeromq
ZeroMQ transport for distributed-process (aka Cloud Haskell) -
HaskellNet
Haskell library which provides client support for POP3, SMTP, and IMAP protocols. -
glirc
Haskell IRC library and console client - Join us on libera.chat #glirc -
http-streams
Haskell HTTP client library for use with io-streams -
graphula
A simple interface for generating persistent data and linking its dependencies -
http-types
Generic HTTP types for Haskell (for both client and server code) -
ngx-export
Nginx module for binding Haskell code in configuration files for great good! -
secure-sockets
A library for making secure connections between servers. -
network-transport-tcp
TCP Realisation of Network.Transport -
linklater
A Haskell library for the Slack API (including real-time messaging!) -
websockets-snap
Snap integration for the websockets library -
http-client-streams
http-client for io-streams supporting openssl
Access the most powerful time series database as a service
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of messagepack-rpc or a related project?
README
messagepack-rpc
Message Pack RPC over TCP.
Right now this implementation only supports TCP, but the plan is to support multiple transports ( UDP, UNIX domain sockets, etc.)
MessagePack-RPC Protocol specification
Reference: http://wiki.msgpack.org/display/MSGPACK/RPC+specification
The protocol consists of "Request" message and the corresponding "Response" message. The server must send "Response" message in reply with the "Request" message.
Request Message
The request message is a four elements array shown below, packed by MessagePack format.
[type, msgid, method, params]
type
Must be zero (integer). Zero means that this message is the "Request" message.
msgid
The 32-bit unsigned integer number. This number is used as a sequence number. The server replies with a requested msgid.
method
The string, which represents the method name.
params
The array of the function arguments. The elements of this array is arbitrary object.
Response Message
The response message is a four elements array shown below, packed by MessagePack format.
[type, msgid, error, result]
type
Must be one (integer). One means that this message is the "Response" message.
msgid
The 32-bit unsigned integer number. This corresponds to the request message.
error
If the method is executed correctly, this field is Nil. If the error occurred at the server-side, then this field is an arbitrary object which represents the error.
result
An arbitrary object, which represents the returned result of the function. If error occurred, this field should be nil.
Notification Message (not yet supported)
The notification message is a three elements array shown below, packed by MessagePack format.
[type, method, params]
type
Must be two (integer). Two means that this message is the "Notification" message.
method
The string, which represents the method name.
params
The array of the function arguments. The elements of this array is arbitrary object.
The Order of the Response
The server implementations don't need to send the reply, in the order of the received requests. If they receive the multiple messages, they can reply in random order.
This is required for the pipelining. At the server side, some functions are fast, and some are not. If the server must reply with in order, the slow functions delay the other replies even if it's execution is already completed.