WinHTTP, http.sys and WebSockets

chapa · 2012-11-29 09:56:34

Hello,

For my current needs I would like to implement support for async WinHTTP client along with new Windows 8 only native support for WinHttpWebSocket* calls.
For server side planning to develop http.sys server with WebSocket functionality (windows8+).

Having http.sys server supporting WebSockets protocol, can be big advantage, as every modern browser (including mobile ones) supports WebSocket protocol.
I also think such functionality will be great benefit to mORMot framework in many aspects.

If someone find it useful and/or have any experience with new Win8 Net api's and want to collaborate with me is welcome.

ab · 2012-11-29 12:42:20

See http://synopse.info/forum/viewtopic.php?pid=5003#p5003
In short, for technical and security reasons, websockets are not compatible with http.sys IOCP mode.
At least until Windows 8 and its HTTP_SEND_RESPONSE_FLAG_OPAQUE option... which may work... or not...

HTTP_SEND_RESPONSE_FLAG_OPAQUE
Specifies that the request/response is not HTTP compliant and all subsequent bytes should be treated as entity-body. Applications specify this flag when it is accepting a Web Socket upgrade request and informing HTTP.sys to treat the connection data as opaque data.
This flag is only allowed when the StatusCode member of pHttpResponse is 101, switching protocols. HttpSendResponseEntityBody returns ERROR_INVALID_PARAMETER for all other HTTP response types if this flag is used.
Windows 8 and later: This flag is supported.

There is a possibility that MS will add websockets support to older Windows with http.sys – the way they added http.sys to XP in SP2. Windows Server 2008 lifespan in the field will be very long, and its not supporting websockets will be a significant disadvantage for the 2008 platform, so maybe one of the future service packs or just Windows updates, will have websockets-compatible version of http.sys for Windows 7/Vista/2008/R2.

What we want to introduce first is not "standard" websockets (which standard?? ) but event-driven model, independent from the HTTP protocol.
See http://synopse.info/fossil/wiki?name=RoadMap for the expectations
and http://blog.synopse.info/post/2012/09/0 … laboration for details.
Long pooling a dedicated kept alive connection may implement this.

chapa · 2012-11-29 12:54:04

It was not compatible with http.sys. Starting Win8+ it is.
http://nbevans.wordpress.com/2011/12/20 … ws-server/

Introducing HTTP_SEND_RESPONSE_FLAG_OPAQUE.

Last edited by chapa (2012-11-29 12:57:13)

ab · 2012-11-29 12:56:37

Yes, I just edited my post just after you sent yours.

I've found a "WebSocket Protocol Component API (Windows)" in http://msdn.microsoft.com/en-us/library … s.85).aspx
This is available in Windows 2008, but for the client side only.

For server side, it seems that there is an optional module in IIS to implement websockets from C# code.
I suspect there is nothing from the C/C++ unmanaged side.

Perhaps the server side implementation may be the following:
- Connection as usual;
- Send "HTTP/1.1 101 Switching Protocols" handshake to switch to websockets mode;
- Use Read/Write just as with an usual TCP/IP protocol.
See http://www.paulbatum.com/2011/09/gettin … ts-in.html

But how may we handle socket-level communication from an http.sys call, after HTTP_SEND_RESPONSE_FLAG_OPAQUE has been replied?
Do you have any idea about precise low-level implementation via http.sys?

chapa · 2012-11-29 13:02:48

There is .NET 4.5 implementation. Although you can use .NET 4.5 on many win OS, using WebSockets namespace work only on Win8+.
So I think it can be done using win apis. This is what I am going to try these days.

Microsoft does not plan to change http.sys implementation on old platforms so far.

ab · 2012-11-29 15:05:14

chapa wrote:

So I think it can be done using win apis. This is what I am going to try these days.

This is very exciting!
If you have any code, we will like very much to include it in our event-driven implementation code!

chapa wrote:

Microsoft does not plan to change http.sys implementation on old platforms so far.

I hope they will make up their mind, as they did for including http.sys in XP SP2.

ab · 2013-03-28 16:41:35

About potential security issues, see http://media.blackhat.com/bh-us-12/Brie … Slides.pdf
and https://bugs.webkit.org/show_bug.cgi?id=32246

Something we have to consider in our mORMot's implementation.

Eric · 2014-08-19 13:08:31

As a conclusion, I would recommend the following, for any project:
Use WebSocket for client notifications only (with a fallback mechanism to long-polling - there are plenty of libraries around);
Use RESTful / JSON for all other data, using a CDN or proxies for cache, to make it scale.

Cloudflare recently began adding websocket support
http://blog.cloudflare.com/cloudflare-n … websockets
though obviously there is no caching

I'm not sure long-polling is a very good alternative to websockets: it will still incur the same scaling issues as websockets (since it has to bypass the CDN), it has associated risks of timeout throughout the wire (can miss some notifications, especially on mobile connections, and you don't have receipts).
The security advantage is over WSS is marginal at best: websockets data goes in well delimited messages that are just as inspectable (or not) as the random binary or malformed data you can pass over http.

That said, for instant notifications the best solution are probably the platform's push notifications, which are centralized on a single service and can thus happen even when an application is not active. Long polling and websockets both require the application to be active.

However for data not specific to a client, such as chat, news, trading data, etc. in my experience good old brute-force high-frequency polling can work very well. It's *very* CDN friendly, if you set 1 second caching f.i., you can serve a million of clients with 1 refresh per second while the main server will get just dozens of requests per second, which is easily manageable.

chapa · 2014-08-19 13:27:45

Thanks for sharing this info

ab · 2014-08-19 14:42:19

@Eric Yes, "good old brute-force high-frequency polling can work very well".
I wrote about CDN and websockets after a discussion we had on your blog.

Thanks for pointing out native "push notifications" abilities of modern platforms.
There seems to be a PhoneGap plug-in for those: see http://devgirl.org/2013/07/17/tutorial- … plication/
So we may be able to use them with SMS applications. But the providers (especially on iOS) add some serious limitation (like 256 bytes maximum length) or security requirements (like explicit SLL certificates).

Eric · 2014-08-19 15:36:46

ab wrote:

But the providers (especially on iOS) add some serious limitation (like 256 bytes maximum length) or security requirements (like explicit SLL certificates).

Yes, they should really only be used to pass commands, rather than data.
For instance for a mail app, you wouldn't pass the new mails, but a command like "check new mails", and the app would then fetch the mails through regular means.

I guess it helps to consider platform notifications as being barely improved remote keypress events

But mostly the whole point is that on mobile devices, either the application is active and it's okay to poll like a madman, or it's not active, and you can use neither websockets nor long polling. Desktops and laptops are a different story of course.

Another advantage of polling when the app is active is that you can report connection lag to the user, which is quite important for a chat app, multi-player game or trading views!
With long poll or websockets, you can't tell connection lag apart from a lack of updates... unless you "ping" frequently, but then you're no better than polling.

ab · 2014-08-20 09:52:14

Very valuable input, Eric, as usual!

Thanks for the feedback.

mpv · 2016-01-28 10:42:02

Arnaud, we create a low level THttpApiWebSocketServer = calss(THttpApiServer) /TWinHttpApiWebSocketClient - the WebSocket server & client based on HTTP API 2.0. Currently we test (20 000 concurrent connection on Core i5 uses 100Mb of memory - very good result IMHO) it and write a sample server (like Project31ChatServer.dpr) and tomorrow will be ready to contribute this code to main repository.
The reason we need it is requirement to handle more when 50 000 concurrent WebSocket connection on production. The current TWebSocketServer implementation are insufficient resources to handle such a large number of connection (because of a dedicated thread for each connection).
We place our current implementation to SynCrtSock.pas unit (we cant create separate unit because many function we need is in implementation section of SynCrtSock.pas)
I want to ask your permission modify your some of your code:
1) We need to move all winHTTPAPI function to dedicated unit as you do with SynWinSock.pas
2) We need to rewrite TWinHTTPWebSocketClient using late binding (since our descendant TWinHttpApiWebSocketClient need to use functions available only on Win8 & UP dlls)
3) Small modifications required for THttpApiServer (some function must be virtual e.t.c)
If you don't mind we do this refactoring? Can we create a brunch during commit or we can commit directly to trunc?

Last edited by mpv (2016-01-28 10:43:56)

ab · 2016-01-28 13:15:11

Very good news!

I would prefer if you use a branch, or send me directly the modified files as a .zip by mail, so that I would review and include them in the trunk.

Thanks for such valuable input!

edwinsn · 2016-01-29 07:48:53

Well done guys!

chapa · 2016-01-29 22:42:44

Great News!

Can not wait to play with the sources.

Long time ago I made some tricks using IOCP and dwsHTTPSysAPI (at that time it supported http.sys 2 over mORMot) and Win8 WebScoket API
Don't know if it will be in any help now but working code was posted 2 years ago at: https://code.google.com/archive/p/dwsockets/

Hope that may help

Last edited by chapa (2016-01-29 22:44:15)

mpv · 2016-01-30 09:53:13

Yes, we know this sources. Some ideas are taken from there

mpv · 2016-01-30 16:04:21

I create a "WinWebSocket" branch - see [d7598a8c7b]
Usage sample are available in SQLite3\Samples\31 - WebSockets\Project31WinHTTPEchoServer.dpr

Current realization don't support WebSocket "protocol" feature.
We need a deep refactoring of existing TWebSocketProtocol class to use it in THttpApiWebSocketServer.AddUrlWebSocket instead of
THttpApiWebSocketServerHandlers (simple record with 4 handlers - OnAccept, OnMessage, OnConnect, OnDisconnect)

@AB - please review our code (me and Valim Orel)

ab · 2016-01-31 20:10:08

Thanks for the branch.

I guess I would create a new unit dedicated to Windows APIs, both client and servers.
Then see if I create another unit, or just enhance SynBidirSock.pas.
We need the new API to work not only with basic message passing, but the whole WebSockets features used by mORMot, i.e. with its own protocol, REST emulation, and so on...

mpv · 2016-02-01 10:07:20

Yes, I understand your requirement. IMHO we need to add some hi-level abstraction instead of TWebSocketProtocol. I don't know how to rewrite current implementation to fit both requirements.
How do you think when you have a time to do something in this direction? (From one hand I have a very limited period of time to implement WebSocket support for my product using HttpAPI and my current omplementation fit all my needs, from other hand I don't want to write code incompatible with mORMot and have a pain with merging in future)

ab · 2016-02-01 11:38:05

I will try to make the future code compatible with what you did.

I guess the TWebSocketProtocol is one level higher that what you are using, so integration should not break anything.

mpv · 2016-02-02 12:59:41

Today we will add protocols, message buffering and new handler onFrame to the THttpApiWebSocketServer. This will simplify realisation of httpAPI specific in TWebSocketProtocol.

ab · 2016-02-02 15:05:39

Nice!

mpv · 2016-02-02 17:53:40

Done in [98d6d261f2]

speedsticko · 2016-02-03 15:32:34

Hi, I found this thread while trying to use the WebSockets in HTTP API 2.0.
@ab did you learn how to do what you asked back in 2012??

"But how may we handle socket-level communication from an http.sys call, after HTTP_SEND_RESPONSE_FLAG_OPAQUE has been replied?
Do you have any idea about precise low-level implementation via http.sys?"

I would like to know how to do that as well. Thank you

Last edited by speedsticko (2016-02-03 18:55:23)

mpv · 2016-02-07 13:58:52

We do a code review for our commit and test our realization on the near-to-production environment. The code is incorrect in some scenarios, so we continue to write it and commit new version ASAP....

ab · 2016-02-07 14:49:33

Thanks for the feedback...

mpv · 2016-05-23 11:54:29

We finish a implementation of WebSockets using HTTP API 2.0 and commit it to branch "WinWebSocket" (BTW merge operation on fossil is very good).
The sample `31 - WebSockets\Project31WinHTTPEchoServer.dpr` give a basic usage.

We test out implementation using synthetic tests and successfully create a 50 000 concurrent webSocket connections. One server-side connection required 5kb of memory (and do not create a separate thread)
Also we deploy a solution based on the THttpApiWebSocketServer to one of our production. The average load is 3000 concurrent WS connection with up to 5000 sometimes. It work 1 week w/o problems (but we use WS only to notify a client about something happens, all other communication is done using HTTP).

cybertrace · 2016-05-24 11:02:52

Hello mpv !

When and where is your code (sample31) available.
I have similar Needs of Connections

Thanks

cybertrace

oz · 2016-05-25 06:36:48

I'm very interested about this topic too!

Could you loose some words about implementation details?
- Encryption: are https connections supported or does it use some other encryption mechanism
- Is there some kind of fallback to mORMots default implementation if http.sys websockets are not available?
- ...
Kind regards

hnb · 2016-05-25 07:41:46

I'd like to use WebSockets on my VPS Linux .

mpv · 2016-05-26 07:36:30

@cybertrace all code are in a fossil branch

>mkdir mormot
>cd mormot
>fossil clone http://synopse.info/fossil synopse
>fossil open synopse
>fossil update WinWebSocket

@oz
https supported & recomended to use instead of http

Sabbiolina · 2016-05-26 09:23:41

I dowload from fossil the source, but simple chat example hangs (64 bit compiled)

I'm wrong ?

mpv · 2016-05-26 11:30:27

I check x64 target compilation for Project31WinHTTPEchoServer.dpr. Delphi IDE hangs during Run- I don't know why, but if I compile and execute executable from a command prompt, all word as expected. Windows version must >= 8.

Sabbiolina · 2016-05-26 14:31:09

I use two Win 8.1 with delphi 10 seattle, with Project31WinHTTPEchoServer (x64) no problem

but others samples hangs.

mpv · 2016-05-27 06:04:27

@Sabbiolina Unfortunately my IDE (XE2) can't debug a x64 target on the Win8 (http://support.embarcadero.com/hu/article/42650). May be you try to debug?

Sabbiolina · 2016-05-27 06:33:19

I'd like to contribute to this development.
32-bit is fine for development
You wrote a simple example client-server (all in Delphi)?

mpv · 2016-05-27 13:26:43

In my case clients is a browsers and server side javaScript based solutions, but we implement a SynWinWebSockets.TWinHTTPWebSocketClient - a low level webSocket client.

Sabbiolina · 2016-05-27 13:38:10

I'm trying SynWinWebSockets.TWinHTTPWebSocketClient.

How to set https ?

cybertrace · 2016-05-30 07:37:09

Thank you mpv fro the Information and your efforts !

Is your Websocket server implementation able to stay connected with ?? 5000 Clients ?
Like original sample 31.
This means a Client connects to the Server and stays connected. The Server sends broadcasts to all conencted Clients.

Thanks

cybertrace

turrican · 2017-01-26 19:49:29

Where is this Unit? I'm very interested to use your implementation.

turrican · 2017-01-26 20:32:17

Ok it's in fossil branch... Can you push this branch on GitHub Repo?
There is some chance to merge with main branch? your implementation is awesome.

Last edited by turrican (2017-01-26 21:00:16)

ab · 2017-01-27 08:10:48

I said I will have eventually to merge the branch!

Note that this WebSockets API will work only on Windows 8/10 and latest Windows Server, IIRC.
It won't be available on Windows 7.

keinn · 2017-06-21 09:52:21

Any news on this branch merge?

mpv · 2017-11-12 15:51:51

@AB - I'm rewrite fossil brunch for WebSocket w/o creating a new units and create a pull request on git. I'm even fix a code style. Let's merge it! Its a big problem for me to merge all mormot changes manually to my codebase...
Project31WinHTTPEchoServer.dpr verified using D7 & XE2 and browser as a client

Last edited by mpv (2017-11-12 15:53:35)

ab · 2017-11-12 21:00:57

Green light!

mpv · 2017-11-13 16:28:41

Merged into trunk (both fossil & git)

EMartin · 2017-11-13 18:34:19

Great work @mpv !!!

Just for curiosity, why not just to use a function for readonly access in https://synopse.info/fossil/info/1ff1e5b5c276dcb5 ?

ab · 2017-11-13 20:21:24

Great!

I will review it and integrate into interface SOA callbacks eventually.

I want also a poll/epoll version under Unix/Linux....

mpv · 2017-11-14 10:17:21

EMartin wrote:

Just for curiosity, why not just to use a function for readonly access in https://synopse.info/fossil/info/1ff1e5b5c276dcb5 ?

Indeed: see [6b4cc8c]. Thanks!

mORMot Open Source

#1 2012-11-29 09:56:34

WinHTTP, http.sys and WebSockets

#2 2012-11-29 12:42:20

Re: WinHTTP, http.sys and WebSockets

#3 2012-11-29 12:54:04

Re: WinHTTP, http.sys and WebSockets

#4 2012-11-29 12:56:37

Re: WinHTTP, http.sys and WebSockets

#5 2012-11-29 13:02:48

Re: WinHTTP, http.sys and WebSockets

#6 2012-11-29 15:05:14

Re: WinHTTP, http.sys and WebSockets

#7 2013-03-28 16:41:35

Re: WinHTTP, http.sys and WebSockets

#8 2014-08-19 13:08:31

Re: WinHTTP, http.sys and WebSockets

#9 2014-08-19 13:27:45

Re: WinHTTP, http.sys and WebSockets

#10 2014-08-19 14:42:19

Re: WinHTTP, http.sys and WebSockets

#11 2014-08-19 15:36:46

Re: WinHTTP, http.sys and WebSockets

#12 2014-08-20 09:52:14

Re: WinHTTP, http.sys and WebSockets

#13 2016-01-28 10:42:02

Re: WinHTTP, http.sys and WebSockets

#14 2016-01-28 13:15:11

Re: WinHTTP, http.sys and WebSockets

#15 2016-01-29 07:48:53

Re: WinHTTP, http.sys and WebSockets

#16 2016-01-29 22:42:44

Re: WinHTTP, http.sys and WebSockets

#17 2016-01-30 09:53:13

Re: WinHTTP, http.sys and WebSockets

#18 2016-01-30 16:04:21

Re: WinHTTP, http.sys and WebSockets

#19 2016-01-31 20:10:08

Re: WinHTTP, http.sys and WebSockets

#20 2016-02-01 10:07:20

Re: WinHTTP, http.sys and WebSockets

#21 2016-02-01 11:38:05

Re: WinHTTP, http.sys and WebSockets

#22 2016-02-02 12:59:41

Re: WinHTTP, http.sys and WebSockets

#23 2016-02-02 15:05:39

Re: WinHTTP, http.sys and WebSockets

#24 2016-02-02 17:53:40

Re: WinHTTP, http.sys and WebSockets

#25 2016-02-03 15:32:34

Re: WinHTTP, http.sys and WebSockets

#26 2016-02-07 13:58:52

Re: WinHTTP, http.sys and WebSockets

#27 2016-02-07 14:49:33

Re: WinHTTP, http.sys and WebSockets

#28 2016-05-23 11:54:29

Re: WinHTTP, http.sys and WebSockets

#29 2016-05-24 11:02:52

Re: WinHTTP, http.sys and WebSockets

#30 2016-05-25 06:36:48

Re: WinHTTP, http.sys and WebSockets

#31 2016-05-25 07:41:46

Re: WinHTTP, http.sys and WebSockets

#32 2016-05-26 07:36:30

Re: WinHTTP, http.sys and WebSockets

#33 2016-05-26 09:23:41

Re: WinHTTP, http.sys and WebSockets

#34 2016-05-26 11:30:27

Re: WinHTTP, http.sys and WebSockets

#35 2016-05-26 14:31:09

Re: WinHTTP, http.sys and WebSockets

#36 2016-05-27 06:04:27

Re: WinHTTP, http.sys and WebSockets

#37 2016-05-27 06:33:19

Re: WinHTTP, http.sys and WebSockets

#38 2016-05-27 13:26:43

Re: WinHTTP, http.sys and WebSockets

#39 2016-05-27 13:38:10

Re: WinHTTP, http.sys and WebSockets

#40 2016-05-30 07:37:09