1

I'm about to write a FastCGI / SCGI (independent implementations) server but I don't have much experience with networked and especially delayed-application programming.

I got a theoretical problem when I think in detail about what I want to do. When the web server sends a TCP Request to my server, the input (bytes) will be processed to the current handler (either FastCGI / SCGI handler). The problem is: what will happen if the response creation needs some time? Lets say the client requests a large file about 10MB. Am I right that the server needs to wait until the 10MB have been flushed to the client? So there is the conclusion: if the client has a low internet connection, my server is blocked until the full 10MB are flushed, isn't it?

What about process requests that need to execute SQL statements for example, they need some time. The server would be blocked for this time, isn't it? Please correct me.

To solve this problem, my only idea is to use threads - and I'm not gonna very experienced with them. And if I understood the SCGI protocol correctly, then threads are not a solution cause it expects an immediate answer to a request. Instead of FastCGI which supports request-ids. What would be your solution?

Joe Ratzer
  • 18,176
  • 3
  • 37
  • 51
The Wavelength
  • 2,836
  • 2
  • 25
  • 44
  • In most cases you can use non-blocking I/O to process multiple requests in parallel. What language are you implementing your server in? – lanzz Jul 09 '12 at 08:23
  • I know I can use non-blocking sockets, but I can't prevent / guarantee that the actual interpreter blocks the whole program. I'm trying to implement an interpreter for a scripting language to make it available for web programming. This is just for fun and to increase my experiences with such things. The server will be written in C++. – The Wavelength Jul 09 '12 at 08:28
  • 1
    You'll either need to fork your interpreter into a separate process, or use threads as you suggested yourself. There is no such thing as an "immediate answer to a request", both FCGI and SCGI clients will wait for your response with some reasonable timeout, likely configurable in the actual client. – lanzz Jul 09 '12 at 08:32
  • Okay... Then it will be harder project than I expected. But - well. It's just for fun :-) The problem is, that SCGI doesn't seem to work with threads, because it doesn't have the ability to work with request-ids. – The Wavelength Jul 09 '12 at 08:36
  • You're trying to build a FCGI/SCGI server with a script language interpreter, but you're already stuck at _blocking I/O_. Yes, this project _will_ be harder than you expect. – lanzz Jul 09 '12 at 08:39
  • Let me explain, I don't think you understood me correctly.. The specification of SCGI is here: [link](http://python.ca/scgi/protocol.txt) - and there is no way to differentiate between two requests. So, if there are two incoming requests, I can only respond to the second if I already responded to the first request, cause the protocol itself can't handle other ways in my opinion. Or do I oversee some things here? **Edit:** Wow - I'm blind. Now I see that there is a one-connection-per-request-theory... Well, forget my posts and I say thanks ;-) – The Wavelength Jul 09 '12 at 08:45

0 Answers0