mORMot Open Source

oz

Member

Registered: 2015-09-02

Posts: 98

Suggestion: Protocol independent interface callbacks

Hi!

I'd really like to use mORMot's interface callback push mechanism in my current mORMot based SOA DDD project. Unfortunately I can't use those interface callbacks because it's current implementation is bound to the WebSockets protocol. Using WebSockets for client/server communication is no option in my target business because of several reasons (firewall policies, proxy policies, etc ...).
Furthermore I really don't like the fact that one is loosing http.sys support when upgrading to WebSockets. Please correct me if i'm wrong about that, but afaik WebSockets are not supported by the http.sys server right now.

That's why i've implemented a message based Polling/LongPolling server-to-client push-like notification solution. The implementation is based on message objects and a publish/subscripe mechanism.
On server-side those notification message objects are stored as JSON in an in-memory table. Simplified code:

type
  TSQLPushNotification=class(TSQLRecord)
  published
    property PushToSessionID: TSessionID;  // Session ID this notification is meant for
    property JsonData: TJsonData; // The data object
  end;

On client-side there's the ability to switch between polling and long polling modes. Polling mode utilizes a background thread who simply is querying the TSQLPushNotification table every X seconds. Long polling mode uses a permanent and dedicated 2nd connection within a background thread. I could go into details here, but I'll assume you are familiar with longpolling mechanism.

Now i'm wondering if it is possible to "cut off" the WebSocket binding of interface callbacks implementation and replace them with any other kind of transmission layer, e.g. my long polling implementation. The idea is to introduce some kind of "push-abstraction-layer" who is not bound to a specific protocol.

What do you think, is it possible to do sth. like that?

Kind regards,
oz.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,660

Website

Re: Suggestion: Protocol independent interface callbacks

AFAIK WebSockets are very firewall-friendly, unless there is packet inspection, which is very doubtful.
A lot of AJAX applications do rely on WebSockets nowadays...
We use it on production with success, even from corporate clients computers.
Once the HTTP link is established, it is just upgraded to WebSockets. The firewall did already allow the connection.
Of course, a HTTP proxy won't let it work... sadly...

By design, the actual implementation is not WebSockets specific.
You could add your own callback mechanism in TSQLHttpServer.NotifyWebSocketsCallback.

I'll try to make it even more uncoupled.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,660

Website

Re: Suggestion: Protocol independent interface callbacks

Update: I've made some more refactoring, so that coupling to WebSockets would be ever more reduced.
See http://synopse.info/fossil/info/1df6154ab2

Now you would be able to enhance a THttpServer class:
- Set   fCanNotifyCallback := true in the constructor, as in TWebSocketServer;
- Override THttpServerGeneric.Callback virtual method, as in TWebSocketServerRest.

Thanks to this, either long or period pooling may be used to implement callbacks.

oz

Member

Registered: 2015-09-02

Posts: 98

Re: Suggestion: Protocol independent interface callbacks

AFAIK WebSockets are very proxy-friendly, unless there is packet inspection, which is very doubtful.

That's exactly the root of all evil. Some of our customers have very restrictive high-security network setups, using packet inspection/traffic analysis. I don't know which kind of firewall is running over there, but it has to be a very good one. Their firewall is able to detect the HTTP WebSocket upgrade change and kills the connection. Unfortunately this behaviour cannot be changed, because it is used to detect other software product who are doing similiar things, but are blacklisted by customer's IT dept. But even disabling packet inpection won't help, because all traffic is routed through a HTTP proxy.

By design, the actual implementation is not WebSockets specific.
You could add your own callback mechanism in TSQLHttpServer.NotifyWebSocketsCallback.

I'll try to make it even more uncoupled.

Thanks for the hint, i'll have a look at TSQLHttpServer.NotifyWebSocketsCallback and will try to find out how that whole thing is working.

oz

Member

Registered: 2015-09-02

Posts: 98

Re: Suggestion: Protocol independent interface callbacks

Update: I've made some more refactoring, so that coupling to WebSockets would be ever more reduced.
See http://synopse.info/fossil/info/1df6154ab2

Now you would be able to enhance a THttpServer class:
- Set   fCanNotifyCallback := true in the constructor, as in TWebSocketServer;
- Override THttpServerGeneric.Callback virtual method, as in TWebSocketServerRest.

Thanks to this, either long or period pooling may be used to implement callbacks.

Arnaud...
What the hell...!
Mate, you are amazingly fast and your support is absolutely outstandig!

You've just managed to decouple things before I could even post my answer regarding your previous message.

Thank's a lot!

I'll have a look at your enhancements.