Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Properly log and react to non-compliant server subprotocol received

See original GitHub issue

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.

            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

Issue Analytics

  • State:open
  • Created 7 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

oberstetcommented, Jan 22, 2021

^ 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 in cloud. All WAMP clients can do all 4 actions (pub, sub, call, register).

bramuscommented, Jan 20, 2021

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)

Read more comments on GitHub >

github_iconTop Results From Across the Web

RFC 6455: The WebSocket Protocol
The handshake from the client looks as follows: GET /chat HTTP/1.1 Host: ... _ The client can request that the server use a...
Read more >
React Error Handling and Logging Best Practices
This article will go over best practices for error handling and logging in React for different scenarios. Let's get started.
Read more >
WebSocket request-response subprotocol - Stack Overflow
WAMP is a proper WebSocket subprotocol, uses WebSocket as transport and JSON ... RPC server responses to client initiated procedure calls.
Read more >
How to Upgrade to React 18
ReactDOM.render is no longer supported in React 18. ... Finally, if your app uses server-side rendering with hydration, upgrade hydrate to ...
Read more >
WebSockets Tutorial: Going Real-time with Node and React
Open a connection, explain your request, receive a response, and then ... The client and server also communicate which subprotocol will be ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found