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
-
Message：
是jsonrpc消息的最上层接口，包含一个sessionid属性。它有两个实现，request代表接收到的jssonrpc 请求， response代表应该返回的响应。这一个接口、两个实现对应的是kurento的定义的通信协议(可参考kurento通信协议)。 -
Transaction:
Transaction 代表的是客户端和服务器之间的一次通信。这个接口最主要的功能就是定义了sendResponse(...)接口。AbstractTransaction是虚类，它定义了internalSendResponse(Response)接口，并用这个接口实现了transaction中定义的各种sendResponse接口。可以这么理解，使用Transaction作为消息相应媒介，最终都需要将各种参数转化为Response，并通过internalSendResponse的实现发送出去。 -
TransactionImp:
kurento jsonrpc项目中唯一的一个transaction实现（继承abstractTransation），但它并没有告诉我们消息具体是怎么发出去的；它定义了一个关键接口 RespondSender，同时拥有一个RespondSender 的属性， 通过这个属性，TransactionImp完成了internalSendResponse的消息发送。 所以，创建一个Transaction的时候，需要给它具体的RespondSender实现。有了具体的实现，其它类就可以利用Transaction 发送相应消息了。 -
RespondSender:
定义了两个接口方法:
public interface ResponseSender {
void sendResponse(Message message) throws IOException;
void sendPingResponse(Message message) throws IOException;
}
这个接口一个用于发送普通相应，一个用于发送心跳。在kurento项目中有两个地方会实现这个接口，一个作为websocket服务器端与浏览器通信；一个作为websocket 客户端与kurento通信。
- 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)来处理。
- 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 发送出去了。
- 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消息。
- 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的通信更好的定义和隔离开，这个项目的代码阅读性和维护性就会大大提高。
