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 21:48 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OFHxgHXxKHA.1692(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >> message > >>> You are trusting the WIKI's too much. >> >> There are also several very successful commercial >> products that are based on FastCGI. > > But it has nothing to do with FASTCGI. You don't know > what it means obviously. > > Look, There are two kinds of web server: > > Application Servers with their application framework > with > embedded server-side languages and built-in ways to > process > 3rd party applications called SCRIPT MAPS. Some > vendors > has their own methods, like ISAPI, ASP, like our > own WCX, like JSP, etc. > > Generic Servers do not and offer generic ways. In > addition, > there are generic server side scripting tools, like > PHP, like > CGI. Apache is one those generic web servers. > > Now, the first kind are commercial systems and speed and > performance is generally better. > > The 2nd one traditionally were SLOWER at the scripting, > CGI - in terms of loading it. PHP become of of Apaches > much used generic scripting language but it had slow load > times. That is where FASTCGI helped for > PHP. > > The alternative for some Web server like custom APACHE > servers instead of using FASTCGI? Do what the others are > doing or done - EMBED IT! > > So its either ONE or the OTHER or just use it as a simple > script map because the hardware is so much faster, it > really doesn't matter any more. > > The only reason today to use an embedded "CGI" language is > to help interface it with the main application server > "DOM" or Data Model. > > Thats the beauty of a language like ASP abeit extremely > high overhead - ever see how long it takes to load a ASP > page? > > So the point here is your FOCUS on fastcgi is off base. > That is not your answer - the answer is the actual code > you write to handle the input and output. FASTCGI does not > help you here. Making this code "FASTCGI" per se is to > make it take INPUT immediately because its already loaded. > 10 years ago, it helped, not today. > > -- > HLS FastCGI does help me handle the input in one crucial way That I have stated several times. FastCGI along with HTML provide a way to put a button on a web-page that the user can use to browse their hard drive to send me a PNG file. It don't really have to have FastCGI on the other end, just something that handles the URL encoded data. Since a fundamental requirement (that seems to have no alternative) is already giving me the data in CGI URL encoded format, why not use FastCGI? Is there another technology that is faster and easier to use in this case?
From: Hector Santos on 16 Mar 2010 21:51 Peter Olcott wrote: > > That is not simple enough for my users. I want a browse > button on a webpage that browses the local hard-drive. <INPUT type="File" name="filename" /> > 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. Geez, you ain't going to get nothing done with this lost focus on "FastCGI". Once again, all you need is a standard C/C++ console application that reads standard input to read your HTTP transfer encoded data block. You either write the multi-part MIME processor or you get a library or class that does it for you. If you write a PHP script, it will do it for you. You can put this under a FASTCGI PHP setup under a certain port and then write a HTTP client do do your testing. However, I don't believe PHP naturally supports memory maps unless you find a public PHP class to expose the WIN32 memory map functions. The WIN32 API has all the memory mapping functions and you will need this to handle the 4GB file. Now, on the wienie side, I don't know what it offers for memory mapping. But I am sure it has something equivalent. -- HLS
From: Peter Olcott on 16 Mar 2010 21:50 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23qdTxMXxKHA.4492(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > > >> You continue to ignore my repeatedly stated requirement >> of 4.0 GB of data (a deterministic finite automaton) that >> must be loaded before execution can begin. If you ignore >> my fundamental requirements you can't possibly provide >> good advice. > > > Heed my advice if you want to get somewhere. Its coming > for FREE! > > If you keeping 4 GB loaded under a 24x7 loaded exe , then > the rest of your system will suffer and you will get > paging delays during idle times. > > That calls for a memory map design requirement. It has > nothing to do with FASTCGI unless youy think this "FastCGI > Language" you wish to use provides a library for you to > automatically do this for you - it does not. Independent > concepts. > > -- > HLS Fundamentally FastCGI differs from CGI in that the app is held in memory rather than re-loaded every time. Although this feature may have limited alternatives, I see no reason to consider them.
From: Peter Olcott on 16 Mar 2010 22:06 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eyHxkRXxKHA.2644(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> >> That is not simple enough for my users. I want a browse >> button on a webpage that browses the local hard-drive. > > > <INPUT type="File" name="filename" /> > >> 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. > > Geez, you ain't going to get nothing done with this lost > focus on "FastCGI". > > Once again, all you need is a standard C/C++ console > application that reads standard input to read your HTTP > transfer encoded data block. You either write the > multi-part MIME processor or you get a library or class > that does it for you. What handles transmission errors? Another thing, I want to immediately close the connection on the first packet if anything besides a 24-bit PNG file is detected. My app MUST be written in C++. I was envisioning this as a single app. One that handles the URL-encoded input, and the same one to process this data. In any case the one that processes this data must remain resident. > > If you write a PHP script, it will do it for you. You can > put this under a FASTCGI PHP setup under a certain port > and then write a HTTP client do do your testing. > > However, I don't believe PHP naturally supports memory > maps unless you find a public PHP class to expose the > WIN32 memory map functions. > > The WIN32 API has all the memory mapping functions and you > will need this to handle the 4GB file. > > Now, on the wienie side, I don't know what it offers for > memory mapping. But I am sure it has something equivalent. > > -- > HLS I have no idea what you are talking about when referring to a memory map. It is not a 4.0 GB file, it is numerous files making up a total of 4.0 GB.
From: Hector Santos on 16 Mar 2010 22:11
Peter Olcott wrote: > Fundamentally FastCGI differs from CGI in that the app is > held in memory rather than re-loaded every time. Didn't I say that a dozen times? > Although this feature may have limited alternatives, I see > no reason to consider them. Consider what? It appears your concern is the 4GB meta data file. You have no choice but to use a memory map regardless if you keep the EXE active 24x7 or not. Your lost focus on "FASTCGI" is not solving the this simple design for you. You are making it far more complicated. -- HLS |