Allow definition of custom network interfaces

[moritz89]

Why:

• Allow user-defined network interfaces to switch been WiFi and mobile modems during run-time
• Allow custom classes to be used as the network, ssl and server classes

This change addresses the need by:

• Creating a new custom WEBSOCKETS_NETWORK_TYPE that expects the user to set network classes
  • WEBSOCKETS_NETWORK_CLASS
  • WEBSOCKETS_NETWORK_SSL_CLASS
  • WEBSOCKETS_NETWORK_SERVER_CLASS

Related issues: #779 #910

[moritz89]

An open questions are:

1. which number should be chosen as the NETWORK_CUSTOM define? The next number (10) or something like 99 or 255?
2. Is NETWORK_CUSTOM the right name?

I would also like to test it with a POC class that toggles between WiFi and TinyGSM, like that published by @Naheel-Azawy : ESP32GSMNetClient before marking this MR as ready.

[Links2004]

using the next free number is fine.

not sure if setting some custom defines via compiler option will work, since WEBSOCKETS_NETWORK_TYPE does also switch some code around and handles include of h files.

will be intresting to see how you solve this.
all of this would be much easier if upstream arduino did provide some interface classes for the network stuff, but thats not the case sadly.

[moritz89]

One option I found that compiles, but isn't pretty is the following. One thing that won't work is using defines to set include paths. Looking into 1-2 other approaches.

lib/arduinoWebSockets/src/WebSockets.h

...
#elif(WEBSOCKETS_NETWORK_TYPE == NETWORK_CUSTOM)
#include <../../../src/CustomNetworkClient.h>
#else
#error "no network type selected!"
#endif
...

src/CustomNetworkClient.h

#pragma once

#include <WiFi.h>

#include "managers/network_client.h"

#define SSL_AXTLS
#define WEBSOCKETS_NETWORK_CLASS inamata::NetworkClient
#define WEBSOCKETS_NETWORK_SSL_CLASS inamata::NetworkClient
#define WEBSOCKETS_NETWORK_SERVER_CLASS WiFiServer

src/managers/network_client.h

#pragma once

#include <Client.h>
#include <WiFiClient.h>

namespace inamata {

class NetworkClient : public Client {
 public:
  NetworkClient();
  NetworkClient(WiFiClient wifi_client);
  virtual ~NetworkClient() = default;

  int connect(IPAddress ip, uint16_t port) final;
  int connect(const char *host, uint16_t port) final;
  int connect(const char *host, uint16_t port, int32_t timeout);
  size_t write(uint8_t) final;
  size_t write(const uint8_t *buf, size_t size) final;
  size_t write(const char *str);
  int available() final;
  int read() final;
  int read(uint8_t *buf, size_t size) final;
  int peek() final;
  void flush() final;
  void stop() final;
  uint8_t connected() final;
  operator bool() final;

  void setCACert(const char *rootCA);
  void setCACertBundle(const uint8_t *bundle);
  void setInsecure();
  bool verify(const char *fingerprint, const char *domain_name);
};

}  // namespace inamata

[moritz89]

A better approach is probably to use the PIMPL approach, an interface class that implements all methods that are called on WiFiClient and WiFiClientSecure and then implement those class methods in the application code. This should be more robust than the relative import #include <../../../src/CustomNetworkClient.h> in the previous approach.

Adding the following file is the minimum to implement stub interfaces in the app source code including the WebSockets library. To keep the WiFiClientSecure behavior, an instance of it can be saved in the NetworkClient::Impl class and then called via the implemented methods (connect(), write(), ...). To connect it to TinyGSM, create an instance of that class...

#include <NetworkClient.h>

struct NetworkClient::Impl {
  ~Impl() = default;

  int a;
  bool b;
};

NetworkClient::NetworkClient() : _impl(new NetworkClient::Impl()) {}
NetworkClient::NetworkClient(WiFiClient wifi_client)
    : _impl(new NetworkClient::Impl()) {}
NetworkClient::~NetworkClient() {}

int NetworkClient::connect(IPAddress ip, uint16_t port) { return 0; }
int NetworkClient::connect(const char *host, uint16_t port) { return 0; }
int NetworkClient::connect(const char *host, uint16_t port, int32_t timeout) {
  return 0;
}
size_t NetworkClient::write(uint8_t) { return 0; }
size_t NetworkClient::write(const uint8_t *buf, size_t size) { return 0; }
size_t NetworkClient::write(const char *str) { return 0; }
int NetworkClient::available() { return 0; }
int NetworkClient::read() { return 0; }
int NetworkClient::read(uint8_t *buf, size_t size) { return 0; }
int NetworkClient::peek() { return 0; }
void NetworkClient::flush() {}
void NetworkClient::stop() {}
uint8_t NetworkClient::connected() { return 0; }
NetworkClient::operator bool() { return 0; }

void NetworkClient::setCACert(const char *rootCA) {}
void NetworkClient::setCACertBundle(const uint8_t *bundle) {}
void NetworkClient::setInsecure() {}
bool NetworkClient::verify(const char *fingerprint, const char *domain_name) {
  return false;
}

I still have to test it with a complete implementation, but it compiles and should allow enough flexibility to implement IO with both WiFi and a mobile modem (or even also Ethernet).

[moritz89]

Here is a VS Code / PlatformIO example project that uses the PIMPL approach.

CustomWebSocketClient.zip

I tried compiling it with Arduino IDE but it failed as it takes the class method implementations and creates duplicate definitions for the NetworkClient class. Also tried using a separate cpp file to implement the NetworkClient class, but that also failed.

I would argue that using a custom network interface is quite advanced anyway, so primarily targeting VS Code / PlatformIO users shouldn't be the biggest deal breaker.