真逗,还有这样设计 TCP 的吗? PROTOCOL,一定要设计 PROTOCOL。如何你不会,最简单的就是用高层 HTTP 1.0 keep-alive.
send - recv 是一一对应的。你发送几次,就应该返回几次包。send 位于发送队列,而 recv 也位于接收队列。每个包的协议结构都应该符合预期,否则就是 Exception,就应该 close 重新 connect。
######对哒~######tcp是可靠的,这种情况你要自己在应用层做crc######
技术简介
json-rpc是基于json的跨语言远程调用协议,比xml-rpc、webservice等基于文本的协议传输数据格小;相对hessian、java-rpc等二进制协议便于调试、实现、扩展,是非常优秀的一种远程调用协议。目前主流语言都已有json-rpc的实现框架,java语言中较好的json-rpc实现框架有jsonrpc4j、jpoxy、json-rpc。三者之中jsonrpc4j既可独立使用,又可与spring无缝集合,比较适合于基于spring的项目开发。
一、JSON-RPC协议描述
json-rpc协议非常简单,发起远程调用时向服务端传输数据格式如下:
{ "method": "sayHello", "params": ["Hello JSON-RPC"], "id": 1}
参数说明:
method: 调用的方法名
params: 方法传入的参数,若无参数则传入 []
id : 调用标识符,用于标示一次远程调用过程
服务器其收到调用请求,处理方法调用,将方法效用结果效应给调用方;返回数据格式:
{
"result": "Hello JSON-RPC",
"error": null,
"id": 1
}
参数说明:
result: 方法返回值,若无返回值,则返回null。若调用错误,返回null。
error :调用时错误,无错误返回null。
id : 调用标识符,与调用方传入的标识符一致。
以上就是json-rpc协议规范,非常简单,小巧,便于各种语言实现。 ######异步通过协议设计来实现,就是每一个包都编一个唯一的编号,收发都带上,这样就知道是否收到你要的了。
看上面 json-rpc 的设计,多么简单,就是一个 id 解决。
######客户提供的Modbus TCP协议;TCP包既然在网络上发,总有掉包的情况;返回的数据只有设备地址和字节数+字节;没有寄存器起始地址;所以单看返回数据是不能分辨的;一定要结合发送请求命令来解释接收的数据######Modbus好像是问答方式,每次只问一条指令,等待回复后再问下一条,等不到就超时处理,不会出现连续发送多个命令的情况啊,这种情况同步处理是比较方便的。在485串口通信比较合适,tcp通信可以采用异步或并发,Modbus效率就比较低了。######请搜索开源构架 通用数据通信socket