socket与rpc的区别

如今的游戏开发，不搞个跨服玩法都不好意思说在做游戏了（当然，也跟游戏类型有关，一些轻度休闲游戏可以排除在外）。跨服玩法的设计，可以进一步激发玩家追求高战力的虚荣心，也可以汇聚玩家数量，避免单服日活跃低呈现死服现象。

不同服务器的玩家，由于数据不在同一个进程里，所以无法直接交互。跨服设计的目标，就是将不在同一个游戏进程的玩家拉到同一个服务器进程。

跨服玩法的技术本质其实是跨进程通信。服务器A跟服务器B进行数据交换。java常用的进程间通信有http，rpc，webservice，消息队列等等。

而跨服游戏设计最常用的是采用RPC以及原生s服务器托管网ocket通信。本文主要来讲述这两种方式的通信方式的区别。

rpc跨服通信

RPC（远程过程调用），简单来说，就是一个进程A向另外一个进程B请求服务。进程A调用进程B的服务，就好像在调用自己进程的服务方法一样，无需关心内部的实现细节。RPC的使用demo如下面所示：

@RpcService(name = "HelloService")
public class HelloServiceImpl implements HelloService {

    @Override
    @RpcInvoker
    public String sayHi(String request) {
        return "hi，" + request;
    }
服务器托管网
}

客户端只需要引用HelloService接口，其实现HelloServiceImpl由服务端提供实现。客户端可以直接以调用本地服务接口的方式调用服务提供者的功能。

rpc的优缺点

优点：

• 简单易用：RPC隐藏了底层通信细节，使用起来简单方便。
• 提高效率：RPC可以将远程调用过程封装成一个接口，并通过一定的序列化和反序列化机制将数据进行传输，减少通信开销，提高效率。
• 提高可维护性：RPC将远程服务封装成接口，可以提高代码的可维护性和可拓展性。
• 跨语言支持：RPC协议通常是跨语言的，可以实现不同语言之间的通信和调用。

缺点：

• 依赖网络：RPC需要依赖网络进行通信，网络不稳定或延迟会影响调用效率和可靠性。
• 难以跟踪问题：由于RPC调用是在不同的进程上进行的，一旦出现问题，调试和跟踪问题会比在本地调用困难。
• 安全性：RPC通信可能会存在安全隐患，需要额外的安全机制来确保通信的安全性。
• 版本兼容性：当服务端接口发生变化时，客户端需要做相应的升级或兼容处理，增加了开发和维护的难度。

总体来说：

RPC在简化开发、提高效率、可维护性和跨语言支持方面具有明显优势，但同时也存在配置复杂、依赖网络、难以调试和安全性等缺点。在使用RPC时，需要根据具体需求和情况进行权衡和选择。

socket通信

rpc专注于面型服务，而socket则是面向底层传输通信。类似于http的请求——响应模式，客户端发送一个请求消息给服务器，服务器处理之后给予一个响应消息。

socket的优缺点

优点：

• 简单易用：Socket编程提供了一种简单而直接的方式来实现网络通信，使得开发者可以自有地创建客户端和服务器端进行通信。
• 灵活性：Socket提供了底层的网络通信接口，允许开发者自定义通信协议和数据格式，从而可以满足各种不同的需求。
• 跨平台性：由于Socket是基于TCP/IP协议的，因此可以在不同的操作系统和平台上进行通信，具有较好的跨平台性。
• 实时性：Socket通信可以实现实时性要求较高的应用，如在线游戏、实时聊天等。

缺点：

• 复杂性：在Socket编程中，开发者需要处理网络通信的各种细节，包括连接管理、数据传输、数据编解码，数据粘包拆包、异常处理等，相对比较复杂。
• 性能：Socket通信的性能受到网络环境和负载的影响，可能出现延迟或带宽受限的情况，影响通信效率。
• 安全性：Socket通信的安全性相对较低，需要额外的加密和认证机制来确保通信的安全性。

总体来说：

Socket在实现网络通信时具有简单易用、灵活性、跨平台性和实时性的优点，但同时也存在复杂性、性能、安全性和编程复杂度等缺点。在使用Socket时，需要根据具体的需求和情况进行权衡和选择。

特别是对于游戏开发来说，需要比较下两者的优缺点

游戏业务选择观点

socket与rpc对比

	socket	rpc
使用方式	服务端收到客户端请求包后返回响应包	客户端面向服务接口，使用简单
传输细节	双方需要关注数据的传输过程	无须关心底层通信
同步调用	客户端调用过程，可以同步调用，亦可异步调用	客户端同步调用，会阻塞当前线程

笔者认为：说到底，rpc只是在通信传输的上层封装了服务而已，其底层主要是socket。当然，也有底层使用http的实现，例如Hession。游戏服务器使用socket来接受所有客户端的请求，本身有一个非常完善的跨进程通信框架。而不同服务器节点的跨服通信，本质跟客户端与服务器的通信一样的，所以无须再引入第三方rpc框架。而且基于socket的通信，可以实现类似于rpc的请求——响应模式，也可以实现异步的消息回调。参考以下接口

public class RpcMessageClient {


   /**
   * 以消息回调的方式请求数据
   * 发送方无须阻塞当前线程
   */
    public static void callBack(IdSession session, Traceable request,         
     RequestCallback callBack) throws CallbackTimeoutException {

   }

  /**
  * 以请求——响应的方式请求数据
  * 发送方必须阻塞当前线程
  */
  public static Object request(IdSession session, Traceable request) throws 
     CallbackTimeoutException {

  }

}

具体代码可参考笔者的游戏服务器开源框架

jforgame游戏服务器开源框架

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: npm换源

前言 做开发，最怕的就是下载 404 的问题。 对于 NPM，下载完后不换源的话，下载依赖包就相当的慢，最后超时下载失败也经常发生。 这时候我们就要改一下 NPM 的 registry 配置，换成国内的镜像源。 先看看源指向哪里： 查看源 先看看源指向哪里： …