github.com/keegancsmith/rpc
Package rpc is a fork of the stdlib net/rpc which is frozen. It adds support for context.Context on the client and server, including propogating cancellation. See the README at https://github.com/keegancsmith/rpc for motivation why this exists. The API is exactly the same, except Client.Call takes a context.Context, and Server methods are expected to take a context.Context as the first argument. The following is the original rpc godoc updated to include context.Context. Additionally the wire protocol is unchanged, so is backwards compatible with net/rpc clients. Package rpc provides access to the exported methods of an object across a network or other I/O connection. A server registers an object, making it visible as a service with the name of the type of the object. After registration, exported methods of the object will be accessible remotely. A server may register multiple objects (services) of different types but it is an error to register multiple objects of the same type. Only methods that satisfy these criteria will be made available for remote access; other methods will be ignored: In effect, the method must look schematically like where T1 and T2 can be marshaled by encoding/gob. These requirements apply even if a different codec is used. (In the future, these requirements may soften for custom codecs.) The method's second argument represents the arguments provided by the caller; the third argument represents the result parameters to be returned to the caller. The method's return value, if non-nil, is passed back as a string that the client sees as if created by errors.New. If an error is returned, the reply parameter will not be sent back to the client. The server may handle requests on a single connection by calling ServeConn. More typically it will create a network listener and call Accept or, for an HTTP listener, HandleHTTP and http.Serve. A client wishing to use the service establishes a connection and then invokes NewClient on the connection. The convenience function Dial (DialHTTP) performs both steps for a raw network connection (an HTTP connection). The resulting Client object has two methods, Call and Go, that specify the service and method to call, a pointer containing the arguments, and a pointer to receive the result parameters. The Call method waits for the remote call to complete while the Go method launches the call asynchronously and signals completion using the Call structure's Done channel. Unless an explicit codec is set up, package encoding/gob is used to transport the data. Here is a simple example. A server wishes to export an object of type Arith: The server calls (for HTTP service): At this point, clients can see a service "Arith" with methods "Arith.Multiply" and "Arith.Divide". To invoke one, a client first dials the server: Then it can make a remote call: or A server implementation will often provide a simple, type-safe wrapper for the client. The net/rpc package is frozen and is not accepting new features.
Readme
This is a fork of the stdlib net/rpc which
is frozen. It adds support for context.Context on the client and server,
including propagating cancellation.
The API is exactly the same, except Client.Call takes a context.Context,
and Server methods are expected to take a context.Context as the first
argument. Additionally the wire protocol is unchanged, so is backwards
compatible with net/rpc clients.
DialHTTPPathTimeout function is also added. A future release of rpc may
update all Dial functions to instead take a context.
ClientTrace functionality is also added. This is for hooking into the rpc
client to enable tracing.
There are many alternatives for RPC in Go, the most popular being
GRPC. However, net/rpc has the following nice
properties:
The nice API is subjective. However, the API is small, simple and composable.
which makes it quite powerful. IDL tools are things like GRPC requiring protoc
to generate go code from the protobuf files. net/rpc has no third party
dependencies nor code generation step, simplify the use of it. A benchmark
done on the 6 Sep
2016
indicated net/rpc was 4x faster than GRPC. This is an outdated benchmark,
but is an indication at the surprisingly good performance net/rpc provides.
For more discussion on the pros and cons of net/rpc see the issue proposal:
freeze net/rpc.
Last forked from commit 292a771 on 16 June 2020.
Cancellation implemented via the rpc call _goRPC_.Cancel.
FAQs
Package rpc is a fork of the stdlib net/rpc which is frozen. It adds support for context.Context on the client and server, including propogating cancellation. See the README at https://github.com/keegancsmith/rpc for motivation why this exists. The API is exactly the same, except Client.Call takes a context.Context, and Server methods are expected to take a context.Context as the first argument. The following is the original rpc godoc updated to include context.Context. Additionally the wire protocol is unchanged, so is backwards compatible with net/rpc clients. Package rpc provides access to the exported methods of an object across a network or other I/O connection. A server registers an object, making it visible as a service with the name of the type of the object. After registration, exported methods of the object will be accessible remotely. A server may register multiple objects (services) of different types but it is an error to register multiple objects of the same type. Only methods that satisfy these criteria will be made available for remote access; other methods will be ignored: In effect, the method must look schematically like where T1 and T2 can be marshaled by encoding/gob. These requirements apply even if a different codec is used. (In the future, these requirements may soften for custom codecs.) The method's second argument represents the arguments provided by the caller; the third argument represents the result parameters to be returned to the caller. The method's return value, if non-nil, is passed back as a string that the client sees as if created by errors.New. If an error is returned, the reply parameter will not be sent back to the client. The server may handle requests on a single connection by calling ServeConn. More typically it will create a network listener and call Accept or, for an HTTP listener, HandleHTTP and http.Serve. A client wishing to use the service establishes a connection and then invokes NewClient on the connection. The convenience function Dial (DialHTTP) performs both steps for a raw network connection (an HTTP connection). The resulting Client object has two methods, Call and Go, that specify the service and method to call, a pointer containing the arguments, and a pointer to receive the result parameters. The Call method waits for the remote call to complete while the Go method launches the call asynchronously and signals completion using the Call structure's Done channel. Unless an explicit codec is set up, package encoding/gob is used to transport the data. Here is a simple example. A server wishes to export an object of type Arith: The server calls (for HTTP service): At this point, clients can see a service "Arith" with methods "Arith.Multiply" and "Arith.Divide". To invoke one, a client first dials the server: Then it can make a remote call: or A server implementation will often provide a simple, type-safe wrapper for the client. The net/rpc package is frozen and is not accepting new features.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
The June TC39 meeting wrapped up this week with eight proposals moving on to the next stage. Here's a quick roundup of the features that the committee approved to advance.
Security News
Cyber extortion in the US and Canada hit record levels in 2023, with ransomware attacks surging and median ransom demands skyrocketing, though fewer companies are choosing to pay ransoms.
Security News
Ecma TC39 is meeting this week and has moved key ECMAScript proposals forward, advancing Deferred Import Evaluation, Error.isError(), RegExp Escaping, and Promise.try to the next stages.
