HTTPD library

[bangkok]

I've got a question regarding the new "HTTPD library" (LiveCode 9)

It's super handy to create a server, with just a few lines :

Code: Select all

on mouseUp
   httpdStart "NewRequest", 12345, "My Server"
   launch url ("http://localhost:" & it)
end mouseUp

on NewRequest pSocketID, pRequest
   httpdResponse pSocketID, 200
end NewRequest

Let's imagine that LiveCode takes several seconds to process the script NewRequest.... If from another browser i make another connexion... I will have to wait for Livecode to finish the script from the first connexion, right ?

To summarize : if the server takes 10 seconds to do something... then any new client will have to wait to end of those 10 seconds, before to be served (10 seconds again etc) ?

There isn't any "multithread" here ?

[FourthWorld]

LC doesn't have scripted multithreading per se, but neither do other languages like Python that support a good number of concurrent users, so by itself that's not necessarily prohibitive.

I haven't read the code for LC's latest HTTPd lib, but socket comms in LC have a callback option that can radically improve concurrent throughput when needed. See the "with <message>" option in the Dictionary entries for relevant commands like "open socket".

By using callbacks, the wait times for network I/O are offloaded to the OS, freeing the LC process to continue to handle more incoming connections even as the OS is still buffering the last one.

Where async behavior is useful and you want to keep the LC process lean, callbacks can deliver more than an order of magnitude more throughput than without them.

But all that said, you probably neither want nor need to use any scripted implementation of HTTPd for a public service, whether written in LC or anything else.

You probably don't want to because, no matter how crafty you are, any scripted implementation will be less efficient than compiled object code, and more so when that code is written by an army of specialists as with Apache, NginX, Lighttpd, etc.

And you don't need to because just about any HTTPd implementation will provide a way to extend request handling using a separate process, such as LC. Apache and Lightttpd support CGI, which uses multiprocessing rather than multithreading for concurrency, and keeps request handling discrete for clear, clean codiing. NginX and others support reverse proxies, where you can set up a pool of workers to handle requests, which can be written in just about any language, including LC.

LC's HTTPd library is an excellent choice for what it was designed for: a lightweight implementation suitable for local development and testing.

But in production, as they say, go big or go home. We have plenty of options for allowing great use of LC on servers, without needing to replicate the generic request brokering part of it that's so well handled by apps designed specifically for that.

[bangkok]

Thanks a lot Richard for your detailed answer.

I think the HTTPD Library is perfect to "fire up" quickly a little socket/web server on a local network.

It's simple as well with regular Livecode commands/functions (the most complicated would be to work on the "headers").

For that matter, it would be interesting to analyse the content of this library.

-is it just a "wrapper", so the only gain would be shorter code ?

-is it offering improved performances ? If yes, which ones ?

[FourthWorld]

Thanks a lot Richard for your detailed answer.

I think the HTTPD Library is perfect to "fire up" quickly a little socket/web server on a local network.

It's simple as well with regular Livecode commands/functions (the most complicated would be to work on the "headers").

For that matter, it would be interesting to analyse the content of this library.

-is it just a "wrapper", so the only gain would be shorter code ?

-is it offering improved performances ? If yes, which ones ?

If performance is important, I've outlined above why any scripted HTTPd won't be the best choice. It's good for what you describe above, for quick local testing, but for that performance is not critical.

As I wrote, I haven't read the code so the best way to get a solid understanding of it would be to read it. You won't need to do much study if you're just using it, but if you want to modify it or write your own it'll be helpful to get a little practice working with sockets in LC - this Lesson is my favorite for learning about sockets:
http://lessons.livecode.com/m/4071/l/12 ... ng-sockets

It uses a different model from HTTP, but provides a good understanding of handling socket comms in LC, with good use of callbacks.

And FWIW there is one HTTPd library I know well because I modified it. This one was the first HTTPd lib in our community, dating back to the late '90s, updated here to meet the requirements of HTTP 1.1 so it works when called with modern browsers:
http://fourthworld.net/lc/mchttpd-4W.zip

I could go on for hours about HTTP - it's a great protocol (and don't let headers scare you - they're structured simply by design, as it nearly everything about HTTP, so a little understanding of the basics goes a long way). But maybe best for now to answer specific questions you have as they come up after reviewing the links provided here and reading the code in LC's HTTPd.