sgcWebSockets is a cross-platform WebSockets library for real-time communication between a client and server. It is written in 100% Delphi Code and designed to be easy to use and flexible, making it a popular choice for developers working on a variety of projects.
One of the best features of sgcWebSockets is its support for multiple platforms. The library can be used on Windows, Linux, Mac, iOS, and Android, making it a convenient choice for developers working on cross-platform projects.
Another key feature of sgcWebSockets is its high performance. The library is optimized for low latency and high throughput, making it suitable for applications that require fast and reliable communication, such as online games and real-time data transfer.
sgcWebSockets also offers a wide range of customization options. Developers can choose from a variety of protocols, such as WebSockets, MQTT, and STOMP, and can also implement their own custom protocols if needed. Additionally, the library provides support for secure connections using SSL/TLS, making it suitable for applications that require secure communication.
In summary, sgcWebSockets is a feature-rich and flexible library for real-time communication over the Web. Its support for multiple platforms, high performance, and customization options make it a top choice for developers working on a variety of projects.
sgcWebSockets implements 4 different types of WebSocket authentication:Basic
implements Basic Access Authentication, only applies to VCL Websockets (Server and Client) and HTTP Requests (client webbrowsers don't implement this type of authentication). When a client tries to connect, it sends a header using AUTH BASIC specification.OAuth2
Client needs to do send an HTTP GET passing username and password, and if authenticated, server response a Session ID. With this Session ID, client open websocket connection passing as a parameter. You can use a normal HTTP request to get a session id using and passing user and password as parameters
example: (user=admin, password=1234) --> http://localhost/sgc/req/auth/session/admin/1234
This returns a token that is used to connect to server using WebSocket connections:
Client open websocket connection passing username and password as a parameter.
example: (user=admin, password=1234) --> http://localhost/sgc/auth/url/admin/1234
Every time a new WebSocket connection is established, sgcWebSockets creates a TsgcWSConnection class where you can access to some properties like identifier, bytes received/sent, client IP... and there is a property called Data where you can store objects in memory like database access, session objects...
SSL support is based on Indy implementation, so you need to deploy openssl libraries in order to use this feature. Supports OpenSSL 1.0 and 1.1 API.
This is a feature that works very well when you need to send a lot of data, usually using a binary message, because it compresses WebSocket message using protocol "PerMessage_Deflate" which is supported by some browsers like Chrome.
Usually Server have more than one IP, if you enable a WebSocket Server and set listening port to 80, when server starts, tries to listen port 80 of ALL IP, so if you have 3 IP, it will block port 80 of each IP's.
Bindings allows to define which exact IP and Port are used by the Server. Example, if you need to listen on port 80 for IP 127.0.0.1 (internal address) and 184.108.40.206 (public address).
SGC Default Protocol implements a QoS (Quality of Service) for message delivery, there are 3 different types:Level 0: "At most once"
where messages are delivered according to the best efforts of the underlying TCP/IP network. Message loss or duplication can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.Level 1: "At least once"
where messages are assured to arrive but duplicates may occur.Level 2: "Exactly once"
where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.
SGC Default Protocol implements Queues to add persistence to published messages (it's only available for Published messages)Level 0
Messages are not queued on ServerLevel 1
only last message is queued on Server, and is sent every time a client subscribes to a new channel or connects to server.Level 2
All messages are queued on Server, and are sent every time a client subscribes to a new channel or connects to server.
sgcWebSockets SGC Protocol supports transactional messaging, when a client commits a transaction, all messages sent by client are processed on server side. There are 3 methods called by clientStartTransaction
Creates a New Transaction on server side and all messages that are sent from client to server after this method, are queued on Server side, until client calls to Commit or RollbackCommit
When a client calls to commit, all messages queued by server are processed.RollBack
When a client calls to RollBack, all messages queued by server are deleted and not processed on server side.
TsgcWebSocketHTTPServer is a component that allows to handle WebSocket, HTTP/1.1 and HTTP/2.0 connections using the SAME port. Is very useful when you need to setup a server where only HTTP port is enabled (usually 80 port). This component supports all TsgcWeBSocketServer features and allows to serve HTML pages.
You can serve HTML pages statically, using DocumentRoot property, example: if you save test.html in directory "C:\inetpub\wwwroot", and you set DocumentRoot to "C:\inetpub\wwwroot". If a client tries to access to test.html, it will be served automatically, example:
Bandwidth Throttling is supported by Server and Client components, if enabled, can limit the amount of bits per second sent/received by socket. Indy uses a blocking method, so if a client is limiting its reading, unread data will be inside client socket and server will be blocked from writing new data to client. As much slower is client reading data, much slower is server writing new data.
SSE are not part of WebSockets, defines an API for opening an HTTP connection for receiving push notifications from a server.
SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.
On Server components, automatically sends a ping to all active WebSocket connections every x seconds.
On Client components, automatically sends a ping to server every x seconds.
On Server components, automatically restart server after unexpected disconnection.
On Client components, automatically reconnect to server after unexpected disconnection.
Client WebSocket components support WebSocket connections through proxies
Web Browsers without WebSockets support, can use Flash to connect to WebSocket Server (example: Internet Explorer from version 6 to 9).
If Flash is not enabled, then tries to connect using Server-Sent Events + XHR.
Load Balancing allows to distribute work between several back-end servers, every time a new client request a connection, it connects to a load balancer server (which is connected to back-end servers) and returns a connection string with information about host, port... which is used by client to connect to a server. If you have for example 4 servers, with this method all servers will have, more or less, the same number of connections, and work load will be similar.
If a client want to send a message to all clients of all servers, just use broadcast method, and this message will be broadcast to all servers connected to Load Balancer Server.