How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Hector Santos on 16 Mar 2010 20:04 Peter Olcott wrote: > > I can't take the several minutes of CGI process spawn time > for my application, (it has to load gigabytes of data into > memory before it begins) thus conventional CGI is > infeasible. Peter, FASTCGI vs CGI, the different is in load time. In the past, that was an ISSUE, not today. You won't be saving any time whatsoever with FASTCGI. If your transaction residence time is over 20-30 seconds, you got other problems with HTTP uploads - i.e. browser uploads. You will need a special client to support a keep alive concept otherwise the browser will think something happen. You would also be do this via AJAX (jQuery with FORMS pluggin) and work in a "progress bar" but unless you Ping/Poll hit the server, you have will timeout issues. -- HLS
From: Hector Santos on 16 Mar 2010 20:05 Peter Olcott wrote: > FastCGI is portable across platforms, and most often faster > than alternatives. You are trusting the WIKI's too much. -- HLS
From: Hector Santos on 16 Mar 2010 20:18 Liviu wrote: > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> I can't take the several minutes of CGI process spawn time for >> my application, (it has to load gigabytes of data into memory >> before it begins) thus conventional CGI is infeasible. > > And you expect that to work on a "dedicated Linux server with 3.0 Ghz > and 2.0 GB RAM, $56.00 per month a GoDaddy.com" exactly how? > > With all due respect, but after reading some of your recent posts, > including naive confusion on how to manage the lifetime of GDI > objects in a DC... I would honestly advise that you team up with > someone more versed in those pesky implementation details (and > before you wonder, no, I wouldn't ever apply). Assuming you _had_ > a glorious idea, better share the glory than run it into oblivion alone. > > Just my 2c, > Liviu Advice worth a thousand pennies. -- HLS
From: Peter Olcott on 16 Mar 2010 20:43 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ugaU9SWxKHA.3896(a)TK2MSFTNGP02.phx.gbl... > > Geoff wrote: > >> On Tue, 16 Mar 2010 17:40:54 -0400, Hector Santos >> <sant9442(a)nospam.gmail.com> wrote: >> >>> Peter Olcott wrote: >>> >>>> I would be doing FastCGI in C++, if I do it. I am >>>> considering FastCGI because I need a completely >>>> portable way for a user to browse for a PNG file to >>>> send to my server. HTML has this built in, and it is >>>> connected to CGI. As far as a protocol goes, this >>>> would be trivial. The user sends a 24-bit PNG file, the >>>> server sends back UTF-8. That's the whole protocol. >>>> Sometimes the UTF-8 is the PNG file translated into >>>> text, and other times it is an error response. >>> Doesn't sound you understand, or at least are showing >>> you don't, what FastCGI is. >>> >>> Forget fastcgi, what you need is a dedicated http server >>> with the built-in procssing or a http server that >>> supports spawning your cgi EXE application as a special >>> URL. >>> >>> You will handle standard INPUT as the encoded data. >>> Simple. >>> >>> Example: >>> >>> int main(char argc, char *argv[]) >>> { >>> DoCGI(); >>> return 0; >>> } >>> >>> where DoCgi() is reads stdin and maybe environment >>> strings. >>> >>> int DoCGI() >>> { >>> // get environment string, if required >>> // read stdin as FORM POSTING encoding data >>> // process, generate response >>> >>> printf("Status: 200\n"); >>> printf("Content-Type: text/text\n\n"); >>> printf"UTF8:%s\n",szResponse); >>> return 0; >>> } >>> >>> For FastCGI, you would prepare your own socket listening >>> server for incoming request from the web server itself. >> >> If he's going to write it in C++ as an application >> wouldn't it be >> better to write it using the ISAPI on an IIS server and >> make his OCR >> application a DLL callable from the server extension? > > > yes, I was going to bring that up but it brain-flash by > me. :) > > Right, ISAPI would be Microsoft's form of a "fast loading" > CGI concept. > >> It seems that >> this would solve the latency problem as well as the >> scalability >> problem since it would be a single server extension >> instance with >> multiple threads. Microsoft would claim this would be >> superior to CGI. >> This might tend to limit it to the Windows platform. I >> don't know if >> there is an ISAPI implementation on Linux. > > > Some other (windows based) web servers do support a ISAPI > interface, off hand, a early version interface. Its > simple a special DLL load that special hooks. I believe I > seen Apache. I don't think it will work under a wienie OS. > > If Peter wants portability, use standard C/C++, PHP, Perl > or some other server-sider scripting language. I would > even look at V8, Googles' new JIT Javascript for the > server - very sweet stuff. LUA is becoming popular but > even the authors say it trade speed for portable > flexibility. > > > > -- > HLS Fastest speed is highest priority, secondary to this is portability, it looks like FastCGI provides both. Another very high priority is minimal development costs. As far as I can tell FastCGI is good here too.
From: Peter Olcott on 16 Mar 2010 20:45
"Liviu" <lab2k1(a)gmail.c0m> wrote in message news:uJsQOVWxKHA.5036(a)TK2MSFTNGP02.phx.gbl... > > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> >> I can't take the several minutes of CGI process spawn >> time for >> my application, (it has to load gigabytes of data into >> memory >> before it begins) thus conventional CGI is infeasible. > > And you expect that to work on a "dedicated Linux server > with 3.0 Ghz > and 2.0 GB RAM, $56.00 per month a GoDaddy.com" exactly > how? > > With all due respect, but after reading some of your > recent posts, > including naive confusion on how to manage the lifetime of > GDI > objects in a DC... I would honestly advise that you team > up with > someone more versed in those pesky implementation details > (and > before you wonder, no, I wouldn't ever apply). Assuming > you _had_ > a glorious idea, better share the glory than run it into > oblivion alone. > > Just my 2c, > Liviu > > > I won't need multiple gigabytes initially. I will need multiple gigabytes eventually, might as well begin with a scalable architecture. |