The Bosch IoT Gateway Software WebSockets Server is configured by the OSGi Configuration. In the WebSockets Server Configuration you will find the following options:

• pingWaitingTime - the interval in seconds at which the WSS will send a system ping to all connected WebSocket instances from all available applications (which want to use System ping. The System ping can be disabled, so if you disable the System Ping you will have to handle the ping on your own (described in 3.)
• cleanerTime - sets the interval in seconds at which your WebSocketApplication will check for closed WebSocket instances which are not removed automatically (in reality it is almost impossible to happen but is provided as additional safety feature) and remove them to release the memory
• lastRemovedCount - sets the number of closed (removed) WebSocket instances for which information is stored.
• maxConnection - the maximum number of WebSockets connections to the WSS (which contains all the WebSocketApplication instances)
• maxConnectionPerWebApplication - the maximum number of WebSocket connections for each WebSocketApplication instance.
  • The maximum number of connections per individual Application can also be set by using the maxAllowedWebSocketConnections() method in your WebSocketApplication. The server will compare the number of connections allowed by the maxConnectionPerWebApplication property and the maxAllowedWebSocketConnections() method and use the lower number. Example for overriding the maxConnectionPerWebApplication property :

DemoWebSocketApplication.java:

public class DemoWebSocketApplication  extends WebSocketApplication {
  .
  .
  .

   // return  the maximum webSocket connections you wish to allow
   // by default this  method returns -1, which indicates
   // that you are going to use the number set in the
   // Web Sockets Server Configuration
public int maxAllowedWebSocketConnections() {
     return 5;
  }
  
  .
  .
  .
}

• Adjusting the pingWaitingTime of the server and the Socket SO_TIMEOUT of the Standalone Server
  • SO_TIMEOUT - the time before the WebSocket closes if it doesn't receive any data. It is recommended to be twice as long as the pingWaitingTime
  • SystemPing - If the WSS ping the WebSocket, and does not receive a pong before the next ping occure the if it doesn't receive a pong back before the next ping occurs, then it closes the WebSocket connection
  • The SystemPing is global, while the Standalone Server's Socket SO_TIMEOUT can be different for each Standalone Server
  • Your SystemPing should always be set to at most half of your Standalone Server's Socket SO_TIMEOUT (the Standalone Server with the lowest Socket SO_TIMEOUT, to be more precise) or you risk webSockets closing due to no data received
  • The SystemPing is sent by a single thread to reduce the overhead of multithreading, so the ping might be sent to a Standalone Server with a delay of a few seconds, that's why it's recommended to have a SystemPing of 20 for example when the lowest Socket SO_TIMEOUT of your Standalone Servers is 35-40 seconds
• Customizing the pinging of your WebSocketApplication
  • The SystemPing is not useful for some WebSocketApplications, that's why you can disable it and use a custom pinging implementation. To disable it you override the method public boolean notUsingSystemPing() make it return true, example:

DemoWebSocketApplication.java:

public class DemoWebSocketApplication  extends WebSocketApplication {
  .
  .
  .

   // return true if  you wish to disable SystemPing
// by default this  method returns  false , which indicates
// that you are going to use the System  Ping
public boolean notUsingSystemPing() {
     return true;
  }
  
  .
  .
  .
}

• This way the SystemPing set in the Web Sockets Server Configuration will be ignored
• In this case you will have to configure the pinging mechanisms on your own
  • Use the sendPing(byte[] data) and sendPong(byte[] data) methods to send Ping and Pong frames
  • Use the onPing(...) and onPong(...) methods to receive Ping and Pong frames