EEBUS server und client websocket connections #171
-
|
Hello Community, I have a fundamental question that I hope you can answer—provided I can express it clearly enough. As part of my familiarization with EEBUS, I took a C# project available on GitHub and further developed it: EEBUS.NET. I am following a strictly object-oriented approach. The code, in its current state, can already collaborate with the controlbox simulator. Currently, the C# code is hardcoded to support the LPC use case and also sends heartbeats regularly. My question relates to the underlying websocket communication. In the example, both EEBUS devices each offer a websocket server and have a websocket client. Both can therefore act as both server and client. Does EEBUS require that all communication must work equally over both connections, or is it sufficient if an EEBUS device, for example, functions only as a server and thus does not communicate as a client? The aforementioned code aims to act as an adapter between a C#-written EMS and a control box. No additional EEBUS device should be connected to the same network to prevent interference. For such a limited use case, the implementation effort could be significantly reduced if the client functionality could be omitted. However, this means that initiating a connection would always have to come from the control box. Is that actually the case in reality? Best regards, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
Hi Klaus, only one connection between two distinct devices may be in use at a given time. It is not allowed to use multiple connections between two distinct devices simultaneously. The SHIP specification specifies rules which connection should be kept. As this is nearly impossible to implement, all stacks have different approaches. See enbility/ship-go#5 Also both devices should be able to initiate a connection. There are devices that won't do this, and it does have quite a few negative effects in the field. There very likely could be control boxes in the field that have the same approach, and then no connection would be established at all. Hope this helps, |
Beta Was this translation helpful? Give feedback.
-
|
Hi @DerAndereAndi , just to make sure: when the EEBUS use cases refer to server and client, does this correspond precisely to the type of WebSocket connection? If I am the server, I offer a WebSocket server, and the other initiates the connection. Particularly in the connection phase, I respond to incoming messages. If I am the client, I initiate, send the initial messages, and wait for the responses. In the long term, however, not both simultaneously. So it should basically be the case that both WebSocket server and WebSocket client functionalities are implemented, and it must be ensured that, if both are active for the same pairing, one of them (keyword smaller SKI) is stopped again. If this interpretation is correct, then you have helped me a lot. I actually think that with the C# code that has been started, it should be possible, with reasonable effort, to implement an EMS control box adapter for all necessary use cases. This wouldn’t be a universally applicable stack like your Go stack, but since it’s written in C#, it could result in a relatively small .NET assembly that can be directly integrated into .NET applications, and potentially also into ones written in C or C++, without requiring additional RPC communication. Without your Go code and the ability to use it to provide a debuggable open-source counterpart for developing an EEBUS application, such an endeavor would be completely impossible! Thanks a lot, |
Beta Was this translation helpful? Give feedback.
-
|
No, the use cases refer to server and client on SPINE level, which features provide (server) and consume (client) data. SHIP server and client is independent from that. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, another misunderstanding cleared up – thank you. With this info I have successfully managed to establish a connection that can be initiated from both sides. It already works to receive and acknowledge consumption limitations. |
Beta Was this translation helpful? Give feedback.
Hi Klaus,
only one connection between two distinct devices may be in use at a given time. It is not allowed to use multiple connections between two distinct devices simultaneously. The SHIP specification specifies rules which connection should be kept. As this is nearly impossible to implement, all stacks have different approaches. See enbility/ship-go#5
Also both devices should be able to initiate a connection. There are devices that won't do this, and it does have quite a few negative effects in the field. There very likely could be control boxes in the field that have the same approach, and then no connection would be established at all.
Hope this helps,
Andreas