Properly log and react to non-compliant server subprotocol received

I got this while being connected to the Poloniex socket for a few hours. I only subscribe to the channels, but I don’t send anything after that.

I have no idea what caused it, I can’t duplicate it, but here it is for if somebody wants to give it a look.

/.../my-project/node_modules/autobahn/lib/transport/websocket.js:99
            var payload = transport.serializer.serialize(msg);
                                              ^

TypeError: Cannot read property 'serialize' of undefined
    at Object.transport.send (/.../my-project/node_modules/autobahn/lib/transport/websocket.js:99:47)
    at self._send_wamp (/.../my-project/node_modules/autobahn/lib/session.js:279:20)
    at Session.join (/.../my-project/node_modules/autobahn/lib/session.js:1156:9)
    at Object.self._transport.onopen (/.../my-project/node_modules/autobahn/lib/connection.js:311:24)
    at WebSocket.<anonymous> (/.../my-project/node_modules/autobahn/lib/transport/websocket.js:118:23)
    at emitNone (events.js:67:13)
    at WebSocket.emit (events.js:166:7)
    at WebSocket.establishConnection (/.../my-project/node_modules/ws/lib/WebSocket.js:887:8)
    at ClientRequest.upgrade (/.../my-project/node_modules/ws/lib/WebSocket.js:778:25)
    at ClientRequest.g (events.js:260:16)

Dependencies, as installed:

┬ autobahn@0.10.1
├─┬ bufferutil@1.2.1
│ ├── bindings@1.2.1
│ └── nan@2.4.0
├── crypto-js@3.1.6
├─┬ msgpack-lite@0.1.20
│ ├── event-lite@0.1.1
│ ├── ieee754@1.1.6
│ ├── int64-buffer@0.1.9
│ └── isarray@1.0.0
├── utf-8-validate@1.2.1
├── when@3.7.7
└─┬ ws@1.1.1
  ├── options@0.0.6
  └── ultron@1.0.2

[oberstet]

^ thanks for clarifying! that use of “WAMP” is completely fine!

well, technically, I still think OCPP could likely be put on top of standard WAMPv2, and that the resulting stack would be “better” … but that is a different matter (just my opinion). Eg with WAMPv2 an Android app (eg AutobahnJava based) could do a routed WAMP RPC into a charging point exposing the RPC endpoint. Both the Android thing, and the charging point sit behind NATs and do not have any listening ports open. Yet the RPC is properly routed via Crossbar.io in cloud. All WAMP clients can do all 4 actions (pub, sub, call, register).

[bramus]

Thanks for the feedback + adjustments to this issue, @oberstet!

---

Regarding OCPP: do know that they’re not using the name WAMP (they use OCPP-J) or state that they have implemented it. They’re simply referring to WAMP as a source of inspiration to solve the same problem WAMP solves. Here’s the relevant passage from their docs:

To encode these request/response relations we need a small protocol on top of WebSocket. This problem occurs in more use cases of WebSocket so there are existing schemes to solve it. The most widely-used is WAMP but with the current version of that framework handling RPCs symmetrically is not WAMP compliant. Since the required framework is very simple we decided to define our own framework, inspired by WAMP, leaving out what we do not need and adding what we find missing.

Basically what we need is very simple: we need to send a message (CALL) and receive a reply (CALLRESULT) or an explanation why the message could not be handled properly (CALLERROR). For possible future compatibility we will keep the numbering of these message in sync with WAMP. Our actual OCPP message will be put into a wrapper that at least contains the type of message, a unique message ID and the payload, the OCPP message itself.

Their first work on this started back in 2012 — back when WAMP v1 was a thing — so it could perfectly be that the passage “handling RPCs symmetrically is not WAMP compliant” is no longer valid.

(Apologies for hijacking this thread with this info)