Websocket Server API

[KozhinovAlexander]

WHAT
Implementation of Websocket Server API would be helpful for embedded devices, which can be configured/controlled over Ethernet.

WHY
To such devices may belong Ethernet connected sound boxes, embedded routers or modems, toys, smart watches etc. Websocket Server API would allow configuration of such devices just right in your local network.

CURRENT SITUATION
Currently Zephyr has only Websocket Client API implementation.

SUGGESTED SOLUTION
We may adapt MinnowServer since it is under GPL2 License

Or implement it same way as MinnowServer.

Any suggestions?

[jukkar]

We may adapt MinnowServer since it is under GPL2 License

The GPL2 license is not compatible with Apache2 license so MinnowServer cannot be used in Zephyr.

[KozhinovAlexander]

We may adapt MinnowServer since it is under GPL2 License

The GPL2 license is not compatible with Apache2 license so MinnowServer cannot be used in Zephyr.

Thank you for your message. Can you change then this Issue to feature request?

[KozhinovAlexander]

@jukkar There were already sample implementation of Websocket Server in v1.13.0. Why is this sample no more in newer versions of Zephyr?

[jukkar]

There were already sample implementation of Websocket Server in v1.13.0. Why is this sample no more in newer versions of Zephyr?

The one in v1.13 was using net_app API which was removed in v1.14. This also meant that the applications using that API were also removed. One of those apps was websocket server. We could create a server sample app for websocket using BSD sockets, but no one has so far volunteered to do it.

[KozhinovAlexander]

There were already sample implementation of Websocket Server in v1.13.0. Why is this sample no more in newer versions of Zephyr?

The one in v1.13 was using net_app API which was removed in v1.14. This also meant that the applications using that API were also removed. One of those apps was websocket server. We could create a server sample app for websocket using BSD sockets, but no one has so far volunteered to do it.

Thank you for very fast and good answer. I am interested in writing this implementation or rewriting the older one sample. I'll try provide a link to my PR later.

[KozhinovAlexander]

@jukkar Does latest version ( v2.3.99 ) of zephyr has http server/client API?

[jukkar]

Does latest version ( v2.3.99 ) of zephyr has http server/client API?

No, we have only client APIs in upstream Zephyr. There is the civetweb module that can be used when server side APIs are needed. There is a sample in samples/net/sockets/civetweb that uses the module.

[KozhinovAlexander]

@jukkar Please correct, if I am wrong:

1. Is it right then, that CivetWeb support WebSocket Server functionality in Zephyr according to this?
2. If 1, holds: Am I right, that WebSocket server application can be implemented just same way as samples/net/sockets/civetweb application?

[jukkar]

• Is it right then, that CivetWeb support WebSocket Server functionality in Zephyr according to this?

• If 1, holds: Am I right, that WebSocket server application can be implemented just same way as samples/net/sockets/civetweb application?

I did not do the civetweb porting and I have not used the API so cannot confirm what you are asking. But the original idea of the civetweb porting was that it could be used in Zephyr as is, so I would expect it to work like you describe above.

[KozhinovAlexander]

@jukkar Do you mean adding http_server.h API functionality from v1.13-branch to current Zephyr is better approach than CivetWeb due to it's huge memory consumption (take a look here)?

[KozhinovAlexander]

Can be solved by this

[jukkar]

Do you mean adding http_server.h API functionality from v1.13-branch to current Zephyr is better approach than CivetWeb due to it's huge memory consumption

IMHO having a native zephyr API is always a better than using external modules. That allows us to better optimize the code usage for zephyr. But if there are no resources to develop/maintain such APIs, good option is to use already existing external code.
If someone sends a PR with HTTP/Websocket server side APIs and is willing to maintain it, then that would be great. So far no one has done that.