Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please extend the docu explizit for other Drafts. #1003

Closed
pezi opened this issue Apr 24, 2020 · 3 comments
Closed

Please extend the docu explizit for other Drafts. #1003

pezi opened this issue Apr 24, 2020 · 3 comments

Comments

@pezi
Copy link

pezi commented Apr 24, 2020

I am developing an OCCP -J 1.5/1.6/2.0 server. I played arround with different libs like Javalin, web container based websocket implementations - but I faced tons of problems due dependency problems in context with a Tomcat environment.

I found this libraray - but my first tries with an OCPP connections failed. Looking at the trace - the server communication failed because the OCPP protocol header were unkown for server - and no fallback was available.

Adding an own Draft to server solves this problem. But I would prefere that important detail is mentioned in the docu, Not everyone is using websockets for only HTTP relateted messages.

@marci4
Copy link
Collaborator

marci4 commented Apr 24, 2020

Hello @pezi,

could you provide the specification you try to implement?
Are you going to implement a Sec-WebSocket-Protocol? Then take a look at https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/example/SecWebSocketProtocolClientExample.java

Thx a lot.

Best regards,
Marcel

@pezi
Copy link
Author

pezi commented May 2, 2020

Sorry for the late anwser! For clarify my issue. The library works fine - there is no error.

But to implement an OCPP server, the code of the counter part of the above client example must include explizit Draft definitions for the preferred OCPP protocols. Otherwise for every OCPP client the connection will be refused by a handshake error.

In short word, using the modfied chat example for an quick test, if this library is feasible for your project, fails on lower level due a protocol missmatch, because there is no default fallback for an unkown protocol. Without digging in the depth, it is not so easy to find the problem for the handshake error.

Other websocket implementations like Javalin, jetty and tomcat have no issue with an unkown protocol. You can restrict the sec-WebSocket-Protocol, but the default behaviour is, every protocol ist welcome.

Is is ok to handle the sec-WebSocket-Protocol more restrictive than other framworks, but it would be nice, if there is a prominent hint in the documentation!

For my OCCP project in the first step I startet with Javalin, works fine, but the code relies on Jetty, which makes this lib incompatible with an tomcat enviroment. Switching to an jetty enviroment was no option - the project should work on every web container.

The tomcat websocket implementation with @serverendpoint annotation has the problem, that the IP of the client can not be retrieved without hacks, because JSR-356 Websocket specification does not expose client IP address.

Therefore I was happy to find this library which meets my needs for a really indepented websocket implementation.

But after a my first quick test and the handshake error I was about to give up. But this library seems to be my last chance for my problemes, and therefore I digged into the problem.

@marci4
Copy link
Collaborator

marci4 commented May 2, 2020

I created #1008 to improve the usability for the Sec-WebSocket-Protocol.

Sorry for the problems the missing documentation caused you!

Best regards,
Marcel

@pezi pezi closed this as completed May 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants