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 22:34 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:lsd0q596g340grpj6g4a5q90m659cmjhpd(a)4ax.com... > See below... > On Tue, 16 Mar 2010 20:31:23 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>message >>news:un$1i$WxKHA.6140(a)TK2MSFTNGP05.phx.gbl... >>> Peter Olcott wrote: >>> >>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>> message >>> >>> >>>>>> FastCGI is portable across platforms, and most often >>>>>> faster than alternatives. >>> >>> >>> >>> >>>>> You are trusting the WIKI's too much. >>>> >>>> Not just Wikis, I have examined at least one book from >>>> Amazon too. >>> >>> >>> So? You really don't know what you are reading Peter. >>> >>>> All That I need is a minimal cost way to keep my 4.0 GB >>>> of data loaded into memory. FastCGI is based on >>>> Sockets. >>> >>> >>> Independent concepts. The twain shall never meet. >>> >>> Honestly, you will be best to use FTP. Some Browser >>> allow a Drag and Drop with FTP backends. FTP has two >>> channels, DATA and COMMAND so you can handle aborts and >>> timeouts better. >> >>That is not simple enough for my users. I want a browse >>button on a webpage that browses the local hard-drive. It >>seems that the only completely portable way to do this is >>HTML and this HTML is hooked up to CGI. Maybe I could >>build >>something from scratch at the other end to handle the >>input. >>I would guess that this would not provide any improvement >>over C++ FastCGI, and cost more development time. >>I am leaning toward Linux now, so a Microsoft thing ported >>to Linux may not be as good as a native Linux thing. > **** > You have confused client-side (browsing a local directory) > with server-side (CGI and > related technologies). Client-side features are usually > implemented with JavaScript > embedded in HTML, or having JavaScript invoke ActiveX (a > deadly combination capable of > creating security holes large enough to drive a railroad > train through, sideways) In my case the only client side code that I need is an HTML file browse widget. Since this is connected to CGI, and FastCGI keeps the app resident, I thought that FastCGI woould be a good fit. > > And you are making unrealisitic assumptions that massive > programs will remain > memory-resident, which is host-OS-specific behavior. My application will be the only thing running on the dedicated server besides the OS. If I only use a fraction of the available RAM (for example 75%) then my app's code and data would have no good reason to be paged out. > > You can safely ignore ISAPI, this is a dangerous > technology which has been largely > replaced by CLR-based solutions (in ISAPI, if you crash > your add-in, you crash all of IIS, > and if you clobber memory, or leak resources, IIS goes > down, too; ISAPI is no longer > supported; for example, ISAPI projects are no longer > building under VS2008 and later > versions. (And maybe under VS2005; I don't use it, so I > never noticed when it went away, > but I remember it from one of the "breaking changes" > lists). > > For FastCGI, you need to handle connection across a > full-duplex pipe, which means you have > to write platform-specific versions of your code, that is, > you will need a Windows version > and a linux version if you are going to run your app on > linux, and the OS interface is > going to be platform-specific (it is platform-independent > only insofar as your host > language is platform-independent, e.g., PHP, PERL, Tcl, > etc.; for these languages, you > rely on the implementor of the OS-interface components of > the interpreter for the language > to handle the "platform independence" aspect; so my PERL > or Python or PHP code remains the > same, but my C or C++ server code is going to have to > change. WHich means if you wrote in > in MFC, you can't have a GUI on it, and if you wrote it in > MFC, you are going to have to > use some product linke mainsoft's port of MFC to > linux/unix platforms (www.mainsoft.com; > not cheap). If you wrote it in pure C++ using only the > stdnadrd C and C++ (STL) libraries > and no OS-specific componenents and NO GUI then you should > be able to port it readily. > > Note that you will have to write the platform-specific > pipe interface using the > appropriate support libraries for your platform. Hector was thinking that FastCGI might be overkill for my purposes, not providing enough functionality for the overhead and learning curve. He suggested simply processing the standard input stream might be a better alternative. What do you think about this? > > TANSTAAFL. > joe > >> >>> >>> -- >>> HLS >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 16 Mar 2010 22:38 "Geoff" <geoff(a)invalid.invalid> wrote in message news:qhf0q55rod7sovcv6sb76ccjlfor4c443c(a)4ax.com... > On Tue, 16 Mar 2010 19:59:35 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >>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. >> > > I did a little Wiki'ing of my own and apparently mod_isapi > is > Windows-Apache-only and doesn't support filters (which is > what I > envisioned for this) so it's a dead end in this case. Also Joe said that it was no good.
From: Joseph M. Newcomer on 16 Mar 2010 22:47 See below... On Tue, 16 Mar 2010 19:43:16 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"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. > **** ISAPI is dead. FastCGI is faster than ordinary CGI but still has no performance guarantees, and yu would be deluding yourself if you believe otherwise. ISAPI is deadly dangerous; for example, it is possible to create an ISAPI component that sniffs passwords and otherwise is capable of compromising security of every other client of that server. AN ISAPI component failure kills the whole server. It is no long a supported technology. You still have the HTTP protocol times, the transmit time across the pipe that is the FastCGI interface, the HTML processing of the result, the transmit time of the result, etc. FastCGI only promises to be faster than the original CGI spec allowed. And I already commented on the "portability" issues. joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 16 Mar 2010 22:52 Geoff wrote: > On Tue, 16 Mar 2010 19:59:35 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >> 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. >> > > I did a little Wiki'ing of my own and apparently mod_isapi is > Windows-Apache-only and doesn't support filters (which is what I > envisioned for this) so it's a dead end in this case. Yeah, today, for script map portability, PHP, is a viable option. It has FASTCGI support, which in my view, only was necessary for lower machine days. The alternative is to use an embedded language and PHP "EMBED" version offers this if you want to add it to your web server. I believe Apache has a module for this too. For Peter, I doubt this is the design issue. Handling the 4 GB of meta data files is the key thing he needs to work out. He erroneously thinks keep the EXE "resident" will solve this performance problem. He has no choice but to use memory map files and now that he said he need to load all them into a vector, he need a class that offers vector MMF virtualization. We have our own CFileMap class which is major part of our server large file database framework. I'm sure there other public classes out there. Here is an Old Microsoft CMemoryMappedFile MFC subclass based off CMemFile: http://support.microsoft.com/kb/142377 -- HLS
From: Peter Olcott on 16 Mar 2010 22:53
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:vag0q5hf07aa6u2rarp37nm3ctrh1oveu8(a)4ax.com... > See below... > On Tue, 16 Mar 2010 19:43:16 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"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. >> > **** > ISAPI is dead. FastCGI is faster than ordinary CGI but > still has no performance > guarantees, and yu would be deluding yourself if you > believe otherwise. Having to load 4.0 GB of data from disk upon every invocation is not much slower than having to load 4.0 GB of data from disk once before all processing begins? > > ISAPI is deadly dangerous; for example, it is possible to > create an ISAPI component that > sniffs passwords and otherwise is capable of compromising > security of every other client > of that server. AN ISAPI component failure kills the > whole server. It is no long a > supported technology. > > You still have the HTTP protocol times, the transmit time > across the pipe that is the > FastCGI interface, the HTML processing of the result, the > transmit time of the result, > etc. FastCGI only promises to be faster than the > original CGI spec allowed. And I > already commented on the "portability" issues. > joe > **** > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |