How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Joseph M. Newcomer on 16 Mar 2010 22:57 On Tue, 16 Mar 2010 20:16:44 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:ueIgi6WxKHA.1692(a)TK2MSFTNGP04.phx.gbl... >> Peter Olcott wrote: >> >> >>> 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. >> >> Dude, FastCGI is not a "Language." Its an idea, a >> methodology that was designed with EARLY needs to speed up >> loading time. You won't have that problem today. > >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. *** And you continue to ignore our observations that there are no technologies that guarantee this, and the timings of program behavior can be swamped by communication times (did I tell you about the 70-second DNS resolution time? Did you know that you can expect delays in integer number of seconds to locate your server?) You fasten on some technology that says it is "faster" and assume it is the answer to your problem; you toss jargon around in ways that those of us who know the technology don't even recognize, such as assertions how FastCGI allows you to have browse buttons in the local Web server, and how it is the perfect answer to all your problems, when we know it isn't anything but another hack whose purpose is to compensate for bad initiali designs (CGI requiring a new process per request). You ignore core issues such as how you are going to port your app so it runs on a linux or Unix server, and how you are going to rewrite it to be platform-independent and possibly even GUI-free, and your unrealistic expectations about how process memory is managed, and how every OS is magically going to behave in the way you wish, without any effort on your part. ANd you refuse to listen when people tell you that you don't understand either the technology or the intrinsic behavior of how an operating system works. You really need to do better research on these technologies before you start making such assertions, or ask questions and pay attention to the answers. I'm not even a Web server expert like Hector, and I can tell you are making nonsensical statements. Listen to him. He sounds like someone who does this for a living, and you should trust what he is telling you. joe > > > Its nonsense to think this is "answer" to >> your problem. In addition, if you worry about processing >> speed, native C/C++ is your choice, so all you are doing >> is writing a CGI application, a console application that >> reads standard input. >> >> If you want productivity, learn PHP. Simple, well >> supported. Then if you really find out that FASTCGI is >> needed for your slow OS and machine, PHP supports it. >> >> The point is your SOLUTION is not FASTCGI, it is the >> actual application that does the work. >> >> -- >> 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 23:01 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23J$4XzXxKHA.4240(a)TK2MSFTNGP06.phx.gbl... > 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 Why can't I simply read in the files in the normal way?
From: Hector Santos on 16 Mar 2010 23:05 Peter Olcott wrote: > It has to do with the client side in the sense that the data > sent from the HTML file browse button is already CGI (thus > FastCGI) URL-encoded. It has exactly and precisely this much > to do with the client side, no more and no less. Is this an ACTIVEX, FLASH or JAVA client side file upload component? If that is the case, what it uses was not defined by you. This would be special pluggin clients. Whats wrong with just using standard HTML INPUT type="file" control with a HTTP upload to a basic HTTP server? As mention many times, you can use standard HTTP or you can design proprierty client/server tools. If you want it in the browser, then you options are: activex - IE Only FLASH - all browsers, browser needs Flash installed Java - all browsers, browser needs Sun Java installed too Newer ones: Flex - Flash on Steriods SilverLight - Microsofts version of Flash/Flex HTML5 - designed to obsolete the above. Future What did I miss? Now, when you using any advanced method other than HTTP, you can define your own communication I/O with a persistent connection. In this case, it isn't FASTCGI - but a simple backend server. Call it want you want, it is still a backend server. -- HLS
From: Joseph M. Newcomer on 16 Mar 2010 23:13 See below... On Tue, 16 Mar 2010 20:50:58 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"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. > **** You obviously did not read the specs. NOWHERE does it say "the app is held in memory"; specifically, http://www.fastcgi.com/drupal/node/6?q=node/15 says * FastCGI processes are persistent: after finishing a request, they wait for a new request instead of exiting. 1. The Web server creates FastCGI application processes to handle requests. The processes may be created at startup, or created on demand. 2. The FastCGI program initializes itself, and waits for a new connection from the Web server. 3. When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends the CGI environment variable information and standard input over the connection. 4. The FastCGI process sends the standard output and error information back to the server over the same connection. .. When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for another connection from the Web server. NOWHERE in this spec does is make ANY claim that the "app is held in memory", only that a new app instance is not launched. Why you would leap to the (erroneous) conclusion that not starting a second app instance means the app is "held in memory" escapes me. What is "held in memory" is up to the platform's specific concepts of address space management for a process in the context of a certain physical memory configuration, and it is likely that some or all of the app's pages will be paged out to make room for other processes. This is your typical "design by wishful thinking" approach where yu make assertions about how things work, which are wrong, and then proceed to systematically ignore eveyone who tells you "but it doesn't work that way". This discussion is shaping up just like the "physical contiguous memory" discussion of a few months ago where you insisted that storage allocators *had* to work in a way that, historically, storage allocators have NEVER worked, and that virtual memory had to work in a fashion that has never been recognized as a way any operating system designer would implement virtual memory. Now you are telling us how FASTCGI works, which is, unfortunately, not the way it works at all. And that it will solve problems it is incapable of (not to mention irrelevant to) solving. So start paying attention to the answers. It will save you a lot of time and effort as you attempt to make technologies do things they never were designed to do, or try to get them to meet specifications they never pretended to meet. 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 23:15
Peter Olcott wrote: >> 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 > Why can't I simply read in the files in the normal way? To load all of the 4GB into memory? Try it. Unless you going completely 64 bit, you will be limited to 32 bit boundaries, and 4GB is the limit. You won't be able to load of it all even if you tried. So you open it like a file and use it as a "Vector" or array but in mapped segments where only part of the file is mapped to memory not all of it. Its called a Mapped View. You can read and write to it like it as was pure memory. The MMF cache memory manager will handle it. The purpose of the above MMF class is to allow you to "read/write" in a near-like-normal way hiding all the WIN32 details for you. Study it Peter. -- HLS |