Search the Community

I believe the Internet Component Suite is amazing and a godsend for Delphi. Thank you for everything you do to support this software. I wish to use WebSockets with ICS Delphi components. I wish to use this in a very large and important system (cannot name it). I am challenged to prototype this because the Overbyte demo OverbyteIcsSslMultiWebServ.dpr has so many features it is impossible to extract a simple webSocket server. I wish to demonstrate ssl/tls and non ssl/tls connections. I am not interested in echo servers/clients. I want servers/clients that can handshake and exchange messages with each either other. How can I demo this. The client side I have been able and is fairly straight forward. The server side is too complex. Please provide a simple Websocket Server application that supports ssl/tls and non ssl/tls connections. Thank you Richard Maley

There is a new ICS sample OverbyteIcsBasicWebServer.dpr in SVN, will be zipped overnight, which is a simplified version of OverbyteIcsSslMultiWebServ ignoring configuration INI files, security features, session data, most demo pages and most logging, and settings for localhost set in code, search for IcsHosts to change IP addresses, etc. But this sample will be a much easier starting point for those developing web or Websocket servers with ICS. I'm going to copy most of the code into another new ICS sample that needs a Websocket server. Angus

I am using the ICS TWSocketServer to communicate between a delphi application and a collection of React applications embedded in Edge browsers. The websocket server is running in the delphi application as are the React web applications. When one of the React applications attempts to connect with the websocket server it sends a json frame with some information needed for authentication. I am able to extract the header information but I cannot figure out how to get the json. Could someone help me? Richard Maley

If you really mean the websocket protocol and not HTTP, there are no header or bodies or protocol, once a websocket is open there is simply a two way TCP stream, and you can send what you like. That stream arrives at the server in the ClientWSFrameRcvdEvent as a string packet and TWebSocketReceivedFrame to tell what typer of data is arriving (text, binary, or closing), it's up to the developer to decide how to interpret that data. Angus

The OverbyteIcsSslMultiWebServ sample serves both web and websocket pages, since all websocket requests start with an HTTP request to port 80/443. But you can remove all the code relating to creating web pages from the sample, the OverbyteIcsSslMultiWebxx units, etc, leaving just the default page and websocket handlers ClientWSxx and WSxx which do the websocket events. I will look at a new simple web server sample, similar to the client snippet samples, but unlikely to be ready for the next release. Angus

Angus Using TSslWebSocketCli, after setting CertifyMethod to CertVerNone, verifypeer no longer gets executed. But the Websocket connects and is ready. If it completely bypasses all internal chain verification AND does not fire verifypeer (which it seems to behave the way you described), how do I do a manual cert verification? These are self signed certs and we validate using hashes, serialnum, pubkey(Mod N) etc... whatever the cert provides that is unique. Setting the CertifyMethod to CertVerBundle or CertVerdWinstore fires verifypeer but the certificates fail regardless of the _OK_ flag. I'm looking for something that may be described as CertVerSelf. This would fire the verifypeer to be used without other verification and the _OK_ would signify pass/fail of the cert. Is there a method in place to accomplish this already?

CertVerifyMethod := CertVerNone is how you bypass internal chain verification. TSslWebSocketCli is derived from TSslHttpRest which has an internal TSslContext, and it's that component that does all the SSL stuff. You can use an external SslContext, see the notes in the rest component, for instance if you are using a hundred rest component instances to download lots of stuff in parallel. If you are using the real WebSocket protocol, it exchanges frames between client and server, and vice versa, and there are several methods WSSendText, WSSendBinary, WSSendFrame, etc, with the OnWSFrameRcvd event being received frames, which you need to check the data type and then process. IsWSConnected does as it says. If you want to send raw data without using WS frames, you are using the wrong component. Angus ,

The purpose of the Websocket is to exchange data with a server, so it opens a connection and does a GET to the path you specify, just as HTTP does, if you don't want that it's not Websockets. I suggest you try using the OverbyteIcsHttpRestTst sample I mentioned, if that does not work you would appear to be using a custom protocol. In a console application, you need to call the message pump after every line that accesses IP functions, ICS is fully event driven. The sample I mentioned makes a single HTTP command, waitis for it to finish and exits. If you are making a series of commands, the console applications gets more complicated. Angus

My apologies for the confusion. Yes Websocket as a protocol. I understand that. I was originally using OverByteSimpleSslCli as an example reference and it uses TSslWSocket and TSslContext and it seemed like a great starting point. So I just now switched to TSslWebSocketCli and can do a little refactoring. But in regards to a console example and implementing events would be very helpful. I'll for sure checkout the Snippets. Thanks Angus.

There is a terminology issue here, Websocket is a specific protocol based on HTTP. TWSocket is the name of the base ICS component for all low level socket operations, and does not handle high level protocols like Websocket. ICS has a TSslWebSocketCli component, there is a simple function doWebSocketClick in the OverbyteIcsSnippets sample you can build and run which accesses one of my servers, or a full example in the OverbyteIcsHttpRestTst sample that should allow you to access your site. ICS has several console samples, but they are no longer in the main distribution not being needed very often, I'll have to look one out. Angus

I offer clients a REST API service to look-up telecommunication information, using the ICS web application server and MS SQL server. It works well, for low volumes of queries, but most users start a new SSL/TLS session for each query, which becomes a limiting factor with performance. So I want to offer a Websocket API as well, so one SSL/TLS session stays open, with just simple request/response packets sent. But how to adapt the REST HTTP request/response to Websocket? My queries are simple URL parameters, ie codelookapi.htm?numhistory=118118. Should the Websocket message just be the arguments or include the full or partial URL as well? Or something else, like a command? Should the initial Websocket request allow arguments, or just open the connection? Should be Websocket response message be just a JSON block, or include a wrapper of some sort, like the HTTP response header? Has anyone done a similar design? I just want to make it easy for clients using standard Websocket client libraries to integrate the new API. Angus

There is a clever improvement in the GetIt ICS installation process, thanks Embarcadero. After the packages have been built and installed, the ICS demos-delphi-vcl project group opens in the IDE, allowing all the samples to be viewed and built, recommend saving the group as a favourite so it can be easily found. The group opens with the OverbyteIcsSnippets project, that provides one button examples of HTTP and FTP multiple file downloading and uploading, HTTP REST requests, Websocket client, TCP socket traffic, and sending email using Mail Queue. Angus

I want to implement a Delphi WebSocket server to send binary data (Stream and byte array) to javascript client. This could be done after receive a client message OR EVEN as unidirectional message so no client message need to be received. Below the pseudocode. var WSServer: TWSocketServer; Case A: I want to send back the binary data after receive a message WSServer.OnClientConnect := procedure (Sender: TObject; Client: TWSocketClient; Error: Word) begin TWebSockSrvClient(Client).OnWebSocketMessage := WebSocketMessage; end; procedure WebSocketMessage(Sender: TObject; Msg: string); var MemStream: TMemoryStream; SocketConn: IWebSocketConnection; begin //create and populate MemStream if (Msg = 'A') then begin SocketConn := TWebSocketSocket(Sender).getConnection; //I need to send back the MemStream but I found only these method: //SocketConn.sendString //SocketConn.sendFrame //SocketConn.sendMessage end; end; Case B: send binary data to some client from button click procedure TForm1.btnSendBufferClick(Sender: TObject); var ArrB: TBytes; begin ArrB := [1, 2, 3]; //I tried WSServer.Client[0].SendTB(ArrB) but is doesn't work end; I check OverbyteIcsWebSocketSrv.dpr demo but only strings are send. Any advice?

Hi, Here may be a bug,would you please have a look?, unit: OverbyteIcsWebSocketCli.pas position: line 1494 ServerKey := Base64Encode(String(SHA1ofStr(s))); ------------ test: x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11 expect: HSmrc0sMlYUkAGmm5OPpG2HaGWk= output:HSmrc0sMlYUkAGmm5OPpG2E/aQ== ------------ test code: procedure TForm1.Button3Click(Sender: TObject); var s : AnsiString; ServerKey:string; begin s := AnsiString(edit1.Text); ServerKey := Base64Encode(String(SHA1ofStr(s))); memolog.Lines.Add(ServerKey); end; node.js - Base64 encoding for Sec-WebSocket-Accept value - Stack Overflow

This Websocket client problem should be fixed in SVN and the overnight zip, assuming it was an ANSI/Unicode casting problem with non-English character set conversions, which I'm unable to reproduce. It did not affect Websocket server which had no casting, and yet always worked against our client. The real problem is ICS has overloaded versions of many functions for ANSI and Unicode, and the compiler does not always choose the correct version if input and output parameters don't match, fixed by using a specific ANSI function. I'm slowly adding TBytes versions for binary data to avoid such problems. but it's a long job. Angus

The new Websocket API is live, when using streamlined requests, it handles about 100 SQL queries a minute from a single thread, although slower if the requests are sent sequentially waiting for a reply. Supporting JSON-RPC 2.0 on the server should not be hard, but does need POST support, I'll look at adding it to the ICS web server database sample. Client is a little harder since JSON-RPC 2.0 JSON-RPC uses a sequential ID to keep track of requests. Angus

I will need to reproduce connection failures before I look into fixing them. So I need a Websocket server to test against. My only suggestion is to try the client against other servers and see if any fail, because no-one else has reported any problems. Angus

Yes I am pretty sure it's a bug, I have debug into ICS and found the two function that caused failure of websocket connection , and am expecting fixing from more official way . I just a little time ago found it and am looking into those code , and not sure exact the correcting till now , so any suggestions are welcome

No idea why this client is not using keep-alive, perhaps their REST library does not support it? The basic Websocket API is working, and the client can access another Websocket interface on the server so seem to know their stuff, now just need to design the pipelining, so that queued queries get returned to the correct client. I'll look at JSON-RPC 2.0 for next time. Angus

If most of all you want to prevent repeated handshakes, that's just a matter of using persistent HTTP connections (keep-alive)...? Another good option could be a RESTful batch API, which in the end helps you optimize more (e.g. database queries). Should you go for the WebSocket idea, the closest thing to a standard is JSON-RPC 2.0, I'd say. There are ready clients available for several languages. Depending on the amount of methods you'll support, consider providing a machine readable spec using OpenRPC.

The TsslWebSocketCli is a very new component, not heard of any using it yet (I use the websocket server for dynamic web pages). What are you using it for? It will need the HTTPRest component, but that will be one of the first to be converted. Adding SSL to V10 is likely to be the hardest part due to the low level changes. Angus

Really interesting! My main purpose is to have the WebSocket/Ssl modules working on my projects which target Android platform. I know that porting ICS V9.0 to Android is likely to be a more complex and time-consuming task. And by initially focusing on ICS V10, i can make quicker progress and gain valuable experience with the newer codebase but I would like to use / port "TSslWebSocketCli" with Ssl.

The websocket protocol has a keep-alive feature, if data is not being sent regularly, it is designed to be kept open. ICS does this for websocket client and server. ICS is quite capable of keeping sockets open for hours, but unless there is some traffic external routers and caches may decide the connection is dead and close it, I had to fix an FTP control channel issue where it was unexpectedly closed after a two hour upload of 50GB, needed to send keep-alives. That was annoying and time consuming, the 50GB uploads worked, but because the control channel was dead were considered failed. But here we are talking about a simple web server, the HTTP protocol allows keep-alive connections usually closing after a couple of idle minutes, I'm not aware it allows hours long connections without any traffic, and certainly the ICS web server is not designed or tested for that concept. Angus

Surely those headers are sent with the WebSocket Upgrade request? Why send them again perhaps each second on the same TCP channel, what would the server do with them? Angus

I guess the point is the WebSockets protocol is supposed to be lightweight, and not cluttered with unnecessary headers. Why are you not sending the header information as WebSocket data packets. A configurable option would be needed to bypass that clean-up code. I'll put it on the list, but taking a break from ICS for a couple of weeks. Angus