Openvidu Server 的WebRTC通讯实现 V

Kurnto Java中定义的一些接口、实现与关系

如下图,Openvidu Server作为webrtc中的信号服务器,在分别与客户端浏览器、KMS通信时都使用了websocket.
与客户端通信时,接收来自客户端的加入会议、发布视频,订阅视频等请求,并且转发连接需要的SDP offer 和 ICE candidate。
与服务器通信时,创建pipleLine,webrtc mediaElement,并编排媒体流,转发ICE canddiate等。


image.png

这些请求和响应通过websocket来完成,通信内容通过JsonRPC方式编码。所需的功能主要由kurento提供的几个类库来完成:kurento-client、kurento-jsonrpc-server, kurento-jsonrpc-client.
kurento-jsonrpc-client:定义了符合jsonrpc通讯的一些接口和实现。
kurento-jsonrpc-server: 定义了充当websocket server端时需要的一些管理类。websocket实际是使用spring的websocket库来完成,而该包在此基础上完成jsonrpc的编码和解码逻辑。
kurento-client: 定义了作为websocket客户端与KMS通信的接口与实现。
以下是相关的一些接口和类:


image.png
  1. Message:
    是jsonrpc消息的最上层接口,包含一个sessionid属性。它有两个实现,request代表接收到的jssonrpc 请求, response代表应该返回的响应。这一个接口、两个实现对应的是kurento的定义的通信协议(可参考kurento通信协议)。

  2. Transaction:
    Transaction 代表的是客户端和服务器之间的一次通信。这个接口最主要的功能就是定义了sendResponse(...)接口。AbstractTransaction是虚类,它定义了internalSendResponse(Response)接口,并用这个接口实现了transaction中定义的各种sendResponse接口。可以这么理解,使用Transaction作为消息相应媒介,最终都需要将各种参数转化为Response,并通过internalSendResponse的实现发送出去。

  3. TransactionImp:
    kurento jsonrpc项目中唯一的一个transaction实现(继承abstractTransation),但它并没有告诉我们消息具体是怎么发出去的;它定义了一个关键接口 RespondSender,同时拥有一个RespondSender 的属性, 通过这个属性,TransactionImp完成了internalSendResponse的消息发送。 所以,创建一个Transaction的时候,需要给它具体的RespondSender实现。有了具体的实现,其它类就可以利用Transaction 发送相应消息了。

  4. RespondSender:
    定义了两个接口方法:

public interface ResponseSender {
    void sendResponse(Message message) throws IOException;

    void sendPingResponse(Message message) throws IOException;
  }

这个接口一个用于发送普通相应,一个用于发送心跳。在kurento项目中有两个地方会实现这个接口,一个作为websocket服务器端与浏览器通信;一个作为websocket 客户端与kurento通信。

  1. ProtocolManager:
    ProtocolManager是一个重要的bean,会在openvidu初始化的时后创建,需要注意的是它被定义为@prototype类型。
 @Bean
  @Scope("prototype")
  public ProtocolManager protocolManager(JsonRpcHandler<?> key) {
    return new ProtocolManager(key);
  }

ProtocolManager有一个重要方法processMessage,这个方法会将接收来的消息跟据类型不同进行处理。连接类型的消息protocolManager自己就处理了;而业务类型的消息,它会调用handlerManager.handleRequest(session, request, responseSender)来处理。

  1. JsonRpcWebSocketHandler:
    它是spring websocket实现框架中,TextWebSocketHandler具体的实现类. 在spring websocket框架中,所有websocket接收到的消息都会被TextWebSocketHandler定义的handleTextMessage方法处理。这个方法签名中,wsSession代表的时一次websocket会话,可以直接用于发送消息。
 public void handleTextMessage(final WebSocketSession wsSession, TextMessage message)

JsonRpcWebSocketHandler实现了这个接口,在这个接口中创建了一个具体的ResponseSender 实现,并把它传给了ProtocolManager

protocolManager.processMessage(messageJson, factory, new ResponseSender() {
        @Override
        public void sendResponse(Message message) throws IOException {

          String jsonMessage = message.toString();
          log.debug("{} Res<- {}", label, jsonMessage);
          sendJsonMessage(jsonMessage);
        }

        @Override
        public void sendPingResponse(Message message) throws IOException {

          String jsonMessage = message.toString();
          log.trace("{} Res<- {}", label, jsonMessage);
          sendJsonMessage(jsonMessage);
        }

        private void sendJsonMessage(String jsonMessage) throws IOException {
          synchronized (wsSession) {
            if (wsSession.isOpen()) {
              ***wsSession.sendMessage(new TextMessage(jsonMessage));***
            } else {
              log.error("Trying to send a message to a closed session");
            }
          }
        }
      }, wsSession.getId());

这行代码中, 创建了一个匿名的ResponseSender对象,从这个对象的实现可以看到,所有的响应消息最终是通过WebSocketSession 发送出去了。

  1. JsonRpcHandlerManager:
    它是JsonRpcHandler的管理类,在这个类的handleRequest方法中,定义了消息如何被处理。
public void handleRequest(Session session, Request<JsonElement> request, ResponseSender rs) {

    try {

      if (handler == null) {
        log.warn("JsonRpcClient has received a request from server but"
            + " there is no JsonRpcHandler configured to manage this" + " request");
        return;
      }

      Class<?> paramsType = getParamsType(handler.getHandlerType());
      Request<?> nonGenRequest;
      try {

        nonGenRequest = MessageUtils.convertRequest(request, paramsType);

      } catch (ClassCastException e) {

        String message = "The handler " + handler.getClass()
            + " is trying to process the request. But request params '" + request.getParams()
            + "' cannot be converted to " + paramsType.getCanonicalName()
            + ". The type to convert params is specified in the"
            + " handler as the supertype generic parameter";

        // TODO Maybe use the pattern handleUncaughtException
        log.error(message, e);

        if (request.getId() != null) {
          rs.sendResponse(new Response<>(null, new ResponseError(0, message)));
        }
        return;
      }

      JsonRpcHandler nonGenHandler = handler;

      TransactionImpl tx = new TransactionImpl(session, request, rs);
      nonGenHandler.handleRequest(tx, nonGenRequest);
      //如果不是异步,且responded是false(可能表示不需要respond),则返回一个空response.
      if (!tx.isAsync() && request.getId() != null) {

        log.debug("Request {} is processed asynchronously", request);

        boolean notResponded = tx.setRespondedIfNot();

        if (notResponded) {
          // Empty response
          rs.sendResponse(new Response<>(request.getId(), ""));
        }
      }

    } catch (Exception e) {

      // TODO Maybe use the pattern handleUncaughtException
      log.error("Exception while processing request {}", request, e);

      ResponseError error = ResponseError.newFromException(e);
      try {
        rs.sendResponse(new Response<>(request.getId(), error));
      } catch (IOException e1) {
        log.error("Exception sending error to client", e1);
      }
    }
  }

上面的这段代买最重要的是:

JsonRpcHandler nonGenHandler = handler;
TransactionImpl tx = new TransactionImpl(session, request, rs);
 nonGenHandler.handleRequest(tx, nonGenRequest);

可以看到,最终消息被包裹在transaction中,被JsonRpcHandler 的具体实现类处理。但是,JsonRpcHandlerManager中并没有定义JsonRpcHandler 的实现类,只是作为接口引用。 所以最终消息是如何被处理的,是由JsonRpcHandler 的实现决定。
Openvidu项目就定义了这个rpcHandler. 他作为全局的bean来处理所有的websocket消息。

  1. JsonRpcClientNettyWebSocket:
    JsonRpcClientNettyWebSocket是AbstractJsonRpcClientWebSocket的具体实现,AbstractJsonRpcClientWebSocket定义了configureResponseSender()方法,会在连接server的时候初始化ResponseSender.
 void configureResponseSender() {
    rs = new ResponseSender() {
      @Override
      public void sendResponse(Message message) throws IOException {
        String jsonMessage = message.toString();
        log.debug("{} <-Res {}", label, jsonMessage);
        sendTextMessage(jsonMessage);
      }

      @Override
      public void sendPingResponse(Message message) throws IOException {
        String jsonMessage = message.toString();
        log.trace("{} <-Res {}", label, jsonMessage);
        sendTextMessage(jsonMessage);
      }
    };
  }

这个ResponseSender发消息的实现很明显是依赖sendTextMessage(String jsonMessage)接口,而这个接口的实现正式在JsonRpcClientNettyWebSocket中,它是websocket 的客户端实现,通过netty库提供的网络接口发送消息。
JsonRpcClientNettyWebSocket作为接收端,它接收到的消息,都调用receivedTextMessage(String message)接口处理,这个接口在abstract父类中已经实现,如果接收到的是请求(kms请求),他会起子线程,调用handlerManager处理。

handlerManager.handleRequest(session, fromJsonRequest(message, JsonElement.class), rs);

可以看到无论是来自浏览器端的websocket客户端请求, 还是来自kms 的websocket服务端请求,最终都是由handlerManager来处理。区别仅仅在于Session和RS对应的场景不同。

根据以上的描述,Transaction定义了发送响应的接口,在TransactionImp中通过定义新接口RespondSender, 作为模板方式实现所有transaction定义的方法。 RespondSender的实现类是真正的发送响应消息提供这。当transaction被用于openvidu的websocket服务端(由spring @eanbleWebsocket提供)处理请求时,RespondSender的实现类实际上就封装了textWebsocketHander提供的websocketSession, websocketSession 用于发送消息; 当transaction被用于openvidu的websocket客户(由JsonRpcNettyWebsocket提供客户端能力)端请求时,RespondSender的实现类实际上封装JsonRpcNettyWebsocket对sendTextMessage的实现。

openvidu在处理客户端websocket请求和服务器端websocket请求,都用了kurentJsonrpc包。虽然由很大的抽象,但也带来了很多困扰,特别是Session 和Transaction,由于场景不同,可能接收、发送于不同的地方。这在阅读openvidu 代码时非常的费力。如果能够把于浏览器的通信和kms的通信更好的定义和隔离开,这个项目的代码阅读性和维护性就会大大提高。

推荐阅读更多精彩内容