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
