美文网首页
Openvidu Server 的WebRTC通讯实现 V

Openvidu Server 的WebRTC通讯实现 V

作者: Charles_linzc | 来源:发表于2021-06-09 08:51 被阅读0次

    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的通信更好的定义和隔离开,这个项目的代码阅读性和维护性就会大大提高。

    相关文章

      网友评论

          本文标题:Openvidu Server 的WebRTC通讯实现 V

          本文链接:https://www.haomeiwen.com/subject/qfjtjltx.html