• Yes, requires OpenSSL
  • No, only Blocking mode
  • Yes, Requires Win8.+

SignalR WebSocket API

From sgcWebSockets 4.1.7 version, SignalR WebSocket API is supported.

SignalR component uses WebSocket as trasport to connect to a SignalR server, if this transport is not supported, an error will be raised. SignalR client component has a property called SignalR where you can set following data:   

  • Hubs: containins a list of hubs the client is subscribing to.
  • ProtocolVersion:  the version of protocol used by the client, supports protocol versions from 1.2 to 1.5
  • UserAgent: user agent used to connect to SignalR server. 


Hubs Messages 

Hubs API makes it possible to invoke server methods from the client and client methods from the server. The protocol used for persistent connection is not rich enough to allow expressing RPC (remote procedure call) semantics. It does not mean however that the protocol used for hub connections is completely different from the protocol used for persistent connections. Rather, the protocol used for hub connections is mostly an extension of the protocol for persistent connections.   

When a client invokes a server method it no longer sends a free-flow string as it was for persistent connections. Instead it sends a JSon string containing all necessary information needed to invoke the method. Here is a sample message a client would send to invoke a server method:   

WriteData('{"H":"chathub","M":"Send","A":["Delphi Client","Test message"],"I":0}');   

The payload has the following properties:

I – invocation identifier – allows to match up responses with requests

H – the name of the hub

M – the name of the method

A – arguments (an array, can be empty if the method does not have any parameters)       


Component has the following events:   



When client connects successfully to server, this event is raised.    



When client is disconnected from server, this event is raised.   



When there is any error in websocket connection.   



The protocol used for persistent connection is quite simple. Messages sent to the server are just raw strings. There isn’t any specific format they have to be in. Messages sent to the client are more structured. The properties you can find in the message are as follows:   C – message id, present for all non-KeepAlive messages M – an array containing actual data.   




When a server method is invoked the server returns a confirmation that the invocation has completed by sending the invocation id to the client and – if the method returned a value – the return value, or – if invoking the method failed – the error. Here are sample results of a server method call:   

{"I":"0"}   A server void method whose invocation identifier was "0" completed successfully.   

"{"I":"0", "R":42}   A server method returning a number whose invocation identifier was "0" completed successfully and returned the value 42.   

{"I":"0", "E":"Error occurred"}   



This event is raised when a KeepAlive message is received from server.