How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Peter Olcott on 16 Mar 2010 18:28 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ea%23kdFVxKHA.5576(a)TK2MSFTNGP05.phx.gbl... > 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. 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. > > 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. > > -- > HLS
From: Peter Olcott on 16 Mar 2010 18:30 "Geoff" <geoff(a)invalid.invalid> wrote in message news:d500q5tcco5952dnl3vokflt7obvgfh50g(a)4ax.com... > 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? 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. FastCGI is portable across platforms, and most often faster than alternatives.
From: Geoff on 16 Mar 2010 19:07 On Tue, 16 Mar 2010 17:30:51 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Geoff" <geoff(a)invalid.invalid> wrote in message >news:d500q5tcco5952dnl3vokflt7obvgfh50g(a)4ax.com... >> 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? 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. > >FastCGI is portable across platforms, and most often faster >than alternatives. > There is an ISAPI implementation add-on for Apache, it's called mod_isapi.
From: Hector Santos on 16 Mar 2010 19:59 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
From: Liviu on 16 Mar 2010 20:01
"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 |