rpc

以太坊的geth java api调用

匿名 (未验证) 提交于 2019-12-02 20:37:20
安装了geth客户端,并且能运行起来 java开发环境 我这里是Linux ,在geth目录下运行命令: . /geth - - datadir /home/zzq/app/geth/data - - rpc - - rpcaddr 192 . 168 . 137 . 134 - - rpcapi "db , eth , net , web3 , miner , personal" console - dev 需要注意的是我这里指定了ip因为geth我是安装在Linux虚拟机的,代码运行在windows,如果不指定就只能127.0.0.1访问了。具体可参考文档 https://github.com/ethereum/wiki/wiki/JSON-RPC 如果是maven项目就好办了,直接写pom(如果不是只能一个个jar下载了) < properties > < geth.version > 3.2.0 </ geth.version > </ properties > <!-- geth 依赖 --> < dependency > < groupId > org.web3j </ groupId > < artifactId > core </ artifactId > < version > ${geth.version} </ version > </ dependency

徒手撸一个简单的RPC框架

℡╲_俬逩灬. 提交于 2019-12-02 20:12:49
来源: https://juejin.im/post/5c4481a4f265da613438aec3 之前在 牛逼哄哄的 RPC 框架,底层到底什么原理 得知了RPC(远程过程调用)简单来说就是调用远程的服务就像调用本地方法一样,其中用到的知识有序列化和反序列化、动态代理、网络传输、动态加载、反射这些知识点。发现这些知识都了解一些。所以就想着试试自己实现一个简单的RPC框架,即巩固了基础的知识,也能更加深入的了解RPC原理。当然一个完整的RPC框架包含了许多的功能,例如服务的发现与治理,网关等等。本篇只是简单的实现了一个调用的过程。 传参出参分析 一个简单请求可以抽象为两步 那么就根据这两步进行分析,在请求之前我们应该发送给服务端什么信息?而服务端处理完以后应该返回客户端什么信息? 在请求之前我们应该发送给服务端什么信息? 由于我们在客户端调用的是服务端提供的接口,所以我们需要将客户端调用的信息传输过去,那么我们可以将要传输的信息分为两类 第一类是服务端可以根据这个信息找到相应的接口实现类和方法 第二类是调用此方法传输的参数信息 那么我们就根据要传输的两类信息进行分析,什么信息能够找到相应的实现类的相应的方法?要找到方法必须要先找到类,这里我们可以简单的用Spring提供的Bean实例管理ApplicationContext进行类的寻找。所以要找到类的实例只需要知道此类的名字就行

Is there a difference between RPC and IPC?

試著忘記壹切 提交于 2019-12-02 19:53:45
Or are they synonyms? Wikipedia is usually great for these purposes. RPC: Remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. IPC: Inter-process communication (IPC) is a set of techniques for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. So, RPC

C++ RPC tutorial? [closed]

瘦欲@ 提交于 2019-12-02 19:43:00
Closed. This question is off-topic. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it's on-topic for Stack Overflow. I want to learn programming C++ (native) on Windows platform for RPC communication. I want to learn both server and client side. I also want to learn some advanced topics, like performance and security. Any good recommended materials to read? (BTW: I Googled a few, but all of them either too brief or COM related, I want to learn pure RPC programming without COM. I am using VSTS 2008 with C++.) Try this: Overview

远程通信的几种选择(RPC,Webservice,RMI,JMS的区别)

好久不见. 提交于 2019-12-02 19:06:51
RPC(Remote Procedure Call Protocol) RPC使用C/S方式,采用http协议,发送请求到服务器,等待服务器返回结果。这个请求包括一个参数集和一个文本集,通常形成“classname.methodname”形式。优点是跨语言跨平台,C端、S端有更大的独立性,缺点是不支持对象,无法在编译器检查错误,只能在运行期检查。 Web Service Web Service提供的服务是基于web容器的,底层使用http协议,类似一个远程的服务提供者,比如天气预报服务,对各地客户端提供天气预报,是一种请求应答的机制,是跨系统跨平台的。就是通过一个servlet,提供服务出去。 首先客户端从服务器的到WebService的WSDL,同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService 服务器进行Request 和Response 当一个数据(XML格式的)被封装成SOAP格式的数据流发送到服务器端的时候,就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析,然后对事物进行处理,处理结束以后再对这个计算结果进行SOAP 包装,然后把这个包作为一个Response发送给客户端的代理类(Proxy Class),同样地,这个代理类也对这个SOAP包进行解析处理,继而进行后续操作

How to handle authentication and authorization with thrift?

喜夏-厌秋 提交于 2019-12-02 18:18:38
I'm developing a system which uses thrift. I'd like clients identity to be checked and operations to be ACLed. Does Thrift provide any support for those? Not directly. The only way to do this is to have an authentication method which creates a (temporary) key on the server, and then change all your methods so that the first argument is this key and they all additionally raise an not-authenticated error. For instance: exception NotAuthorisedException { 1: string errorMessage, } exception AuthTimeoutException { 1: string errorMessage, } service MyAuthService { string authenticate( 1:string user,

webService 提供服务的方式

孤街醉人 提交于 2019-12-02 18:12:31
经常听到公司同事谈论resf,rpc,最近花时间了解了下 resf,rpc,soap这些都是 WebService提供服务的实现方法 随着应用的不断壮大,需要将服务独立出来,给客户端提供服务。目前常用的方法就是: RPC 所谓的远程过程调用 (面向方法) SOA 所谓的面向服务的架构(面向消息) REST 所谓的 Representational state transfer (面向资源) 如果说 RPC 是基于方法调用(method),那么 SOA 则是基于 消息, 基于方法调用通常会与特定的程序语言 耦合起来,而后者则与具体的实现语言无关, 所以在一定程度上得到大公司的支持。 RPC即远程过程调用,简单的说就是像调用本地服务(方法)一样调用服务器的服务(方法). 通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式. REST不是一种协议,它是一种架构,一种WebService如果能够满足REST的几个条件,则它通常称这个系统为Restful的 REST架构风格最重要的架构约束有6个: 客户-服务器(Client-Server) 通信只能由客户端单方面发起,表现为请求-响应的形式。 无状态(Stateless) 通信的会话状态(Session State)应该全部由客户端负责维护。 缓存(Cache)

What differentiates a REST web service from a RPC-like one?

徘徊边缘 提交于 2019-12-02 17:41:09
I have a web application that uses AJAX to grab JSON data from the server. It requires that the user first log in with their browser so that a cookie can be set. Only the GET and POST verbs are used, where GET is for retrieving data and POST is for any operation that modifies data. From what I understand, REST differs from the above method in that the user authentication information is sent with every request and the PUT and DELETE verbs are used as well. My question is, what benefits does a REST web service have over the RPC-like method, if the end point is only meant to be a user's browser?

RPC框架之Thrift分析

ε祈祈猫儿з 提交于 2019-12-02 16:51:55
一、简介 1、Thrift是Facebook开发的跨语言的RPC服务框架。随后贡献给Apache开源组织。成为RPC服务的主流框架。 2、特点: 优点: 跨语言,支持java、c/c++、python等多种编程语言 IDL定义接口函数和数据类型 支持二进制传输,效率高 支持多种工作模型,单线程模型、线程池模型、非阻塞模型 缺点: 文档不多 各版本不兼容,升级不方便 二、分析 Thrift分为服务端(server)和客户端(Client)两个对应的部分。代码分层设计,分为Transport(传输层)、Protocol(协议层)、Processor(处理层)和Server(服务层)。 1、主要的处理流程: 各部分类图: 传输层 TTransport: 客户端传输层抽象基础类,主要方法:read、write、flush、open、close。read、write方法为核心 TSocket 与 TNonBlockingSocket: 分别是基于BIO和NIO客户端传输类。 TSocket 持有Socket,设置输入输出流使用1K的BufferedStream, TNonBlockingSocket 持有SocketChannel,read和write方法里的byte会每次被wrap成一个ByteBuffer。 TServerSocket 与 TNonBlockingServerSocket

Thrift入门示例

坚强是说给别人听的谎言 提交于 2019-12-02 16:05:50
RPC基本原理 RPC(Remote Procedure Call),远程过程调用,大部分的RPC框架都遵循如下三个开发步骤: 1. 定义一个接口说明文件:描述了对象(结构体)、对象成员、接口方法等一系列信息; 2. 通过RPC框架所提供的编译器,将接口说明文件编译成具体的语言文件; 3. 在客户端和服务器端分别引入RPC编译器所生成的文件,即可像调用本地方法一样调用服务端代码; RPC通信过程如下图所示 通信过程包括以下几个步骤: 1、客户过程以正常方式调用客户桩(client stub,一段代码); 2、客户桩生成一个消息,然后调用本地操作系统; 3、客户端操作系统将消息发送给远程操作系统; 4、远程操作系统将消息交给服务器桩(server stub,一段代码); 5、服务器桩将参数提取出来,然后调用服务器过程; 6、服务器执行要求的操作,操作完成后将结果返回给服务器桩; 7、服务器桩将结果打包成一个消息,然后调用本地操作系统; 8、服务器操作系统将含有结果的消息发送回客户端操作系统; 9、客户端操作系统将消息交给客户桩; 10、客户桩将结果从从消息中提取出来,返回给调用它的客户过程; 所有这些步骤的效果是,将客户过程对客户桩发出的本地调用转换成对服务器过程的本地调用,而客户端和服务器都不会意识到有中间步骤的存在。 这个时候,你可能会想,既然是调用另一台机器的服务,使用