[twsocket] Design principles of WebSockets server for ICS
Hi Everybody, I have a WebSockets server based on ICS. It is currently implemented as a tcp-server (TWSocketServer without any modifications) with custom descendant of TWSocketClient, which provides all necessary functionality for WebSockets handshaking and data exchange. We could use it in ICS projects right away, but I'm not sure if this is a proper approach. Lets consider an ordinary use-case for websockets: a client is a browser's built-in websocket, and the socket is instantiated by a web-page code. The web-page itself is normally served by a web-server located on the same host which is an endpoint of the websocket connection. So, standard http- port is used by the web-server, and a dedicated tcp-server (for websockets) is required to listen at a non-standard port, which may be not allowed by some firewalls. On the other hand, we can suppose that the web-server is an ICS-based web-server. So, it is feasible to combine web-server and websockets-server in a single component, serving websockets on standard http-port. I think, this is only possible if the current THttpServer component (actually, meaning with the THttpConnection component) is extended and reworked. That is deriving new components from the existing ones will require overriding of most important virtual methods and copy-pasting much of http-related code into the new methods, what is not good. The reason for this is the need to interlace little yet distinctive websocket code fragments with existing code. In other words, it would be necessary anyway to transform such methods as THttpConnection.ConnectionDataAvailable into a highly templatized methods splitted into several new virtual stages/branches each. Are there some other design principles for implementing this? I'd be glad to hear your opinions, considerations on which variant is the best, and suggestions on implementation. If the general consesus is that current design is sufficient for the moment, I'll send the sources to Francois. Best wishes, Stan -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
I think, this is only possible if the current THttpServer component (actually, meaning with the THttpConnection component) is extended and reworked. That is deriving new components from the existing ones will require overriding of most important virtual methods and copy-pasting much of http-related code into the new methods, what is not good. Surely your WebSocket (whatever that is, never heard of it) application should be based on THttpAppSrv which is specifically designed for custom web applications, but still supports static web pages? Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
Hello Stan, As I understand, you are trying to - or you already have - implement RFC6455, server side (http://tools.ietf.org/rfc/rfc6455.txt). Is that correct ? There are several ways to implement that using ICS. I don't know the best one since I have not read RFC6455 in details. Candidates are TWSocket, TWSocketServer, THttpServer and THttpAppSrv. Gave the candidates in order of inheritance. At first glance, the highest level is the best because you will less reinvent existing code. By the way, I don't really understand the real world use case for such WebSockets in the context of a IC/Delphi/WebServer application. Unless you have to support and existing client application, it is IMO not very interesting. Maybe I'm wrong. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -Message d'origine- De : twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] De la part de Stan Envoyé : dimanche 4 mars 2012 16:09 À : ICS support mailing Objet : [twsocket] Design principles of WebSockets server for ICS Hi Everybody, I have a WebSockets server based on ICS. It is currently implemented as a tcp-server (TWSocketServer without any modifications) with custom descendant of TWSocketClient, which provides all necessary functionality for WebSockets handshaking and data exchange. We could use it in ICS projects right away, but I'm not sure if this is a proper approach. Lets consider an ordinary use-case for websockets: a client is a browser's built-in websocket, and the socket is instantiated by a web-page code. The web-page itself is normally served by a web-server located on the same host which is an endpoint of the websocket connection. So, standard http- port is used by the web-server, and a dedicated tcp-server (for websockets) is required to listen at a non-standard port, which may be not allowed by some firewalls. On the other hand, we can suppose that the web-server is an ICS-based web-server. So, it is feasible to combine web-server and websockets-server in a single component, serving websockets on standard http-port. I think, this is only possible if the current THttpServer component (actually, meaning with the THttpConnection component) is extended and reworked. That is deriving new components from the existing ones will require overriding of most important virtual methods and copy-pasting much of http-related code into the new methods, what is not good. The reason for this is the need to interlace little yet distinctive websocket code fragments with existing code. In other words, it would be necessary anyway to transform such methods as THttpConnection.ConnectionDataAvailable into a highly templatized methods splitted into several new virtual stages/branches each. Are there some other design principles for implementing this? I'd be glad to hear your opinions, considerations on which variant is the best, and suggestions on implementation. If the general consesus is that current design is sufficient for the moment, I'll send the sources to Francois. Best wishes, Stan -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
On 04-03-2012 15:24, François Piette wrote: I don't really understand the real world use case for such WebSockets in the context of a IC/Delphi/WebServer application Now that web browsers are implementing it (http://en.wikipedia.org/wiki/WebSocket#Browser_support), it would be nice to have support for it from ICS too. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
Now that web browsers are implementing it (http://en.wikipedia.org/wiki/WebSocket#Browser_support), it would be nice to have support for it from ICS too. OK, so this is just server push under another name. To implement either the client or server using ICS, we need the opposing client and servers for demonstration, debugging and testing. For a server, we need HTML page code with the Javascript to access the websockets server from a browser. For a client, we need a URL of an existing public server using websockets, which will presumably be dynamically updating a web page. If people reading this list wish to contribute either or both of these testing environments, adding websockets will be much faster. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
Hi Angus, Now that web browsers are implementing it (http://en.wikipedia.org/wiki/WebSocket#Browser_support), it would be nice to have support for it from ICS too. OK, so this is just server push under another name. You are wrong, because this is not just another name of the server push, but a different prototol. Also this is a full-duplex connection. To implement either the client or server using ICS, we need the opposing client and servers for demonstration, debugging and testing. As a rule, the client is a modern browser. For a server, we need HTML page code with the Javascript to access the websockets server from a browser. Of course, I have such a test page in the distribution kit. For a client, we need a URL of an existing public server using websockets, which will presumably be dynamically updating a web page. I did not have a goal to implement websockets client, though it can be done with support of other units which are already implemented for websockets support, such as handshaking, framing, and message building. If people reading this list wish to contribute either or both of these testing environments, adding websockets will be much faster. I'll send what I have. Angus Best wishes, Stan -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design principles of WebSockets server for ICS
Hi Francois, As I understand, you are trying to - or you already have - implement RFC6455, server side (http://tools.ietf.org/rfc/rfc6455.txt). Is that correct ? You are right, but we code supports both hixie and hybie protocols. By the way, I don't really understand the real world use case for such WebSockets in the context of a IC/Delphi/WebServer application. Unless you have to support and existing client application, it is IMO not very interesting. Maybe I'm wrong. The websockets supersede the old AJAX approach with requesting each portion of data by separate http-request. WebSockets allow you to do the same without overheads on HTTP-headers, which may be very large in comparison with your data, if you're exchanging with small data elements. Best wishes, Stan -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
