Jump to content

stijnsanders

Members
  • Content Count

    106
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by stijnsanders


  1. I have an alternative implementation here,

    it is build with the larger xxm project, which is primarily designed to be a 'generic' layer between IIS, Apache https, CGI or SCGI, and provides a way to use the very same binary with any of these.

    Regretfully, not all environments (and their xxm handler) support websockets. xxm has a bare-bones HTTP service as well which till now offers the best performance (but no TLS, compression or even logging...)

    if you specifically want to work with websockets, see the example project here also.

    • Like 1

  2. Have you considered the OnIdle event on tApplication? (optionally with the ApplicationEvents component)?

    In other words, instead of using a kind of timer, you can have the message pump itself run something between each message! I've had a scenario once that would make the process take 100% of one CPU, but I've recently discovered Windows' own SwitchToThread to have a kind-of timer using Windows' own task switching 'cadence'. If you need finer grained timing, I would suggest QueryPerformanceTimer


  3. Ah well, IIS does its own thread management, that's right. And you have a choice: You could do all the work for a request in the HttpExtensionProc call you get and return HSE_STATUS_SUCCESS, it works really great for small responses and when it's pretty clear what the extension is supposed to do, and each request won't take too much time of a worker process. But, if you want do have more control over threads, over different kinds of things happening depending on the requests that come in, and especially keep threads free when they're waiting on other processes, the best you can do is return rightaway with HSE_STATUS_PENDING, and manage the threads to do the heavy lifting yourself. The threads IIS uses to call your HttpExtensionProc, aren't supposed to run for long times, and probably are also limited in number and will cause 503 errors when they're all occupied. If you want to keep IIS responsive and have more control what happens when a really big stream of requests is hammering the server, I strongly suggest HSE_STATUS_PENDING.

     

    Well, actually, I would suggest you try some other options as well. I've been working with something one level down: HTTPAPI. There's a little thing called http.sys which (modern) IIS uses itself to do the actual requests. And the API is open for us to use as well. If you're sure you actually don't need much of the overhead IIS offers (strong security, filters, access control, logging, etc.) or are confident you can do it (better?) yourself, check it out.

     

    Also there are open-source alternatives to web servers as well. And there's much more than Apache httpd out there if you care to look. (Yes, done that) I've been able to do CGI and SGI with some of them, but not FastCGI (yet?) mainly because I really dislike how the protocol was designed. NginX is making a great name for itself as a server that's particularly fit to configure for heavy loads. And I've also played around a bit with Lighttpd.

     

    And — if you really, really — feel fit for the challenge, you could always try to roll your own. I've gotten the best of heavy load results with that, but that really is eliminating overhead done to the max. (And also I haven't been able to put much time into that project since a while before HTTP v2 is out, and HTTP v3 is around the corner...)


  4. I would consider setting this to 0. Unless you're sure you want your web service to halt when there are a lot of people at once, which seems like the very thing you'd like to avoid.

    In the work I've done with ISAPI (not using Delphi's own TISAPIApplication though, sorry) I just keep queueing incoming requests in a queue the thread-pool can take from with any worker thread that happens to be available for work...

    (Though I seem to have written a comment there to consider doing something when there's a lot of incoming requests...)

    The rationale would be that other things would fail first before your thing does: memory runs out, or network sockets run out, or IIS runs out of execution contexts (and throws 503 itself when it deems appropriate...

    • Like 1

  5. Could this be due to a setting of isolation level on this client? I remember when you had to switch between named pipes and TCP to get the connection working, there's a lot of other settings you can tweak and change. Perhaps there's one that is causing this.


  6. I've stopped using WinInet and use XMLHTTP or ServerXMLHTTP classes from an imported MSXML2_TLB (without wrappers), mainly because MSXML2 has gotten a lot of security updates and involves less code to do the exact same as your code snippet.

    Older Windows versions don't support TLS 1.3, so chances are those computers may really be unable to contact certain websites over https. If you really have to make the web-call, I would advice to look into curl. Either vind a libcurl DLL that works, or package curl.exe and call it yourself using CreateProcess.


  7. You're not showing us enough code, so we're not sure what you're trying to do. The <meta> tag you're supposed to use is <meta charset=""> not content. It also can only be either "iso-8859-1" or "iso-8859-8", you can't offer a combination there. What you can do is use "utf-8" or "utf-16" and be asured that the TStringStream you're building is written using the correct encoding, but we can only check if that's done right if you show us more code.


  8. Just to get to know MongoDB and what it's about, I once started the hard way and created a really bare-bones just-the-essentials connector to MongoDB: http://github.com/stijnsanders/TMongoWire

    So, no, I'm afraid the plain MongoDB isn't quite fit for embedding. A basic install would require a basic mongoDB installation alongside with your software.

    What you could do depending on what you would need from the data-component, is store your own list of JSON documents indexed by their "id" value... But that won't allow you to do clever queries like mongo has with the "$" prefixed query fields...


  9. I've heard about projects that would use Delphi for all user-facing interfaces like forms and configuration tools, but have all the deep-down stuff done by DLL's written in C++ that the Delphi front-end uses to make stuff work.


  10. Would you like to share some code? From what I learned about isapi from making xxm, it's important to catch any and all exceptions in your code, and not have them pass through into IIS as it can't properly handle Delphi exceptions and indeed may terminate the worker process. Typically you have a try except inside of every callback handler, the except clauses set an appropriate return value, but never re-raises, perhaps writes to an extra log.


  11. Hmm, yes if it's static content, there would be sense in keeping a cache of the gzipped-data somewhere and serve that on subsequent requests. If it's dynamic content on the other hand, you might suspect this data to be one-off specifically for each request. So if there's a lot of it (and might take some time to generate, typically longer than it takes to transmit over to the client...) and you're having transfer-encoding chunked (which enables keeping the connection open when the response is sent over) then you should use TZCompressionStream's capability to zip a next chunk based on the existing stream...


  12. I rember something about old Delphi versions acting up when you've done some of the most recent windows updates.

    If I recall correctly, you need to delete a key "LM" under HKEY_CURRENT_USER\Software\Borland\Delphi\6.0 and then start Delphi to re-create that value with the right data.

    • Like 1
    • Thanks 1

  13. I would respectfully request you to have a look at an alternative web platform I've been working on: https://github.com/stijnsanders/xxm

     

    It's not really designed to do REST endpoints, but all of the worker threads are COM enabled and also the main interface to generically connect all of the things any HTTP server environment offers is a COM interface.

    If I understand correctly, mapping each request to and from the different COM objects and their methods should be set up. This could be quite a manual task, or in the best case partially generated from scripts based on the IDL, but for a public facing HTTP endpoint it's important to do input sanitation and other security measures.


  14. Guys, are all of you missing this? Due to the Pascal calling convention, the first (plain!) argument of a function maps into the same register(s), so in fact this is valid and correct code. Though strictly I agree it looks weird and like as if in 'normal' cases the Value members aren't assigned to Result members. Bit in fact, they're already there! So what is actually needed is a 'type size limiting' cast, which is exactly what Result.x:=SmallInt(Result.x); is.

    • Haha 1
    • Confused 1
×