1.6. 文献
[JSON] [OCPP_IMP_S] [RFC2119] http://www.json.org/ OCPP SOAP implementation specification “Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. March 1997. http://www.ietf.org/RFC/RFC2119.txt [RFC2616] “Hypertext Transfer Protocol?—?HTTP/1.1”. http://tools.ietf.org/html/RFC2616 [RFC2617] “HTTP Authentication: Basic and Digest Access Authentication”. http://tools.ietf.org/html/RFC2617 [RFC3629] “UTF-8, a transformation format of ISO 10646”. http://tools.ietf.org/html/RFC3629 [RFC3986] “Uniform Resource Identifier (URI): Generic Syntax”. http://tools.ietf.org/html/RFC3986 [RFC5246] “The Transport Layer Security (TLS) Protocol; Version1.2”. http://tools.ietf.org/html/RFC5246 [RFC6455] “The WebSocket Protocol”. http://tools.ietf.org/html/RFC6455 [WAMP] [WIKIWS] [WS]
6
http://wamp.ws/ http://en.wikipedia.org/wiki/WebSocket http://www.websocket.org/ 2. 效益与问题
Web Socket协议在【RFC6455】里有定义。早期的草案工作实现Web-Socket规范的存在，但OCPP-J实现使用在 [ RFC6455]描述的协议。
注意，WebSocket TCP之上的定义自己的消息结构。在TCP级别，通过WebSocket发送的数据，被包裹在一个WebSocket帧头。使用框架时，这是完全透明的。然而对于一个嵌入式系统工作时， WebSocket图书馆不可用并且她/他必须依据[RFC6455] 正确地框架信息。
3. 连接
用OCPP-J连接一个充电点和一个中央系统，中央系统扮演一个WebSocket服务器，充电点扮演WebSocket客户端。
3.1. 客户端请求
建立一个连接，充电点启动一个WebSocket连接如在[ RFC6455 ] 第4节“所描述的：开场握手”。
OCPP-J在URL和WebSocket子协议施加额外的约束，在下面的4.1.1和4.1.2这两个部分会详细介绍。
3.1.1. 连接URL
为了启动一个WebSocket连接，充电点需要一个URL（[ RFC3986 ]）连接。这个URL从此被称为“连接URL”。这个连接URL是特定于充电点的。充电点的连接URL包含充电点身份使中枢系统知道充电点属于哪一个WebSocket连接。
支持OCPP-J的中央系统必须至少提供一个OCPP-J端点URL，从该点电荷应该得到它的URL连接。这OCPP-J端点URL可以是任何以“ws”或“wss”方案URL。充电点如何获得OCPP-J端点URL不是本文档的范围。
为了得到连接URL，充电点通过添加到路径“/”， 然后识别唯一地充电点串来修改OCPP-J端点URL（U + 002f固相线）。这种独特的标识字符串必须成编码如在 [RFC3986 ] 描述中一样有必要。
7
例1：身份为”CP001”的一个点电荷连接到一个中央系统OCPP-J端点URL”ws://centralsystem.example.com/ocpp”这会给出下面的连接URL： ws://centralsystem.example.com/ocpp/CP001
例2：身份为“RDAM123”的一个点电荷连接到一个中央系统OCPP-J端点URL wss://centralsystem.example.com/ocppj”这将给以下网址： wss://centralsystem.example.com/ocppj/RDAM 123
3.1.2. OCPP 版本
精确的OCPP版必须在SEC- WebSocket协议字段指定。这应该是下列值之一： 表1：OCPP版本 版本 1.2 1.5 1.6 2.0
对于OCPP1.2，1.5和2.0是官方WebSocket子协议名称的值。他们本身注册在因特网编号管理局。
注意：OCPP1.2和1.5在列表中。由于WebSocket解决方案中的JSON是独立的实际消息内容，所以也可用于旧版本OCP。请记住，在这些情况下，实现还应该保持对基于SOAP的解决方案的支持，以便互操作。
将OCPP版包含在OCPP-J端点URL字符串的一部分是很好的实践。如果你运行一个Web服务，可以在同一个OCPP-J端点URL处理多个OCPP版本，这是没有必要的课程。
8
Websocket 子协议名称 OCPP1.2 OCPP1.5 OCPP1.6 OCPP2.0
3.1.3. 一个开放的HTTP请求的例子
以下是一个OCPP-J连接握手的开放HTTP请求的例子： GET /webServices/ocpp/CP3211 HTTP/1.1
Host: some.server.com:33033 Upgrade: websocket Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: ocpp1.6, ocpp1.5 Sec-WebSocket-Version: 13
黑体部分是在每一个WebSocket握手请求时会出现，其他部分都是具体的例子。 在
这
个
例
子
中
，
中
央
系
统
的
OCPP-J
端
点
URL
是
\。充电点的唯一标识符”CP3211”，因此请求路径为\。
根据sec- WebSocket 协议报头，充电点在这里显示，它可以使用OCPP1.6J和OCPP1.5J，更偏向于前者。
在这个例子中，另一头是HTTP和WebSocket协议的一部分，与那些实施OCPP-J除第三方WebSocket库之外无关。这些标题的作用在[RFC2616] 和 [RFC6455]中有解释。
3.2. 服务器响应
在接收充电点的要求，中央系统与响应完成握手如在[RFC6455] 描述。 以下为OCPP-J-specific申请条件：
? 如果中央系统不能识别URL路径中的点电荷标识符，它应该发送状态404的HTTP响应
和中断WebSocket连接如在[ RFC6455 ]所描述。
? 如果中央系统不同意使用一个由客户提供的子协议，它必须与一个反应不一秒
WebSocket协议头，然后立即关闭WebSocket连接完整的WebSocket握手。
所以如果中央系统接受上述例子的要求并且同意使用充电点OCPP1.6J，中央系统的响应将如下所示：
9
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: OCPP1.6
黑体部分是在每一个WebSocket握手响应中找到，其他部分都是具体的例子。 Sec-Web Socket-Accept的作用在[ RFC6455 ]中有解释。 SEC -WebSocket协议头指示服务器将在此连接使用OCPP1.6J。
3.3. 更多信息
对于那些做自己实现WebSocket握手的，[WS]和[ WIKIWS ]给更多关于WebSocket协议的信息。
4. RPC框架
4.1. 介绍
一个WebSocket是一个全双工连接，简单来说就是数据可以从管道中的进出，进出之间没有明确的关系。根据请求和响应，WebSocket协议本身没有提供任何方法与消息。对这些请求/响应关系，我们需要在顶部的WebSocket有个小协议。这个问题发生在WebSocket更多的案例，所以有现有的方案去解决它。使用最广泛的是WAMP（见[WAMP]）。但随着现有的版本框架处理RPC不是WAMP兼容当前版本。由于所需的框架很简单我们决定定义自己的框架，受到WAMP的启发，删除了我们不需要的并加上了我们发现所丢失的。
基本上，我们需要的是非常简单的：我们需要发送一个消息（电话）和收到回复（callresult）或解释为什么信息不能妥善处理（callerror）。对于未来可能的兼容性我们将对这些消息进行编号同步服务器。我们实际的OCPP消息将被放入一个至少包含消息的类型的包装，一个独特的消息ID和有效载荷，该OCPP消息本身。
10