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 23:16 See below... On Tue, 16 Mar 2010 17:28:45 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"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. *** So, in other words, if I happen to be so unfrotunate as to make a request on your server and there IS no instance of the process, that in fact, I cannot expect 500ms reponse time but instead can expect MINUTES of delay! NOte that all FASTCGI promises is that your process does not exist or require a restart once it has been launched; it does not promise the pages will be "held in memory". joe ***** > >> >> 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 > 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:19 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:6ng0q5pbktq73efm697rl1tf18jv6dhknn(a)4ax.com... > 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?) > That is horrendous. I doubt if it is frequent, and local caching would hopefully prevent it from recurring. > 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 It seems to me that most of you guys continue to simply ignore some of my most fundamental design requirements. App load time for me can be several minutes, app execution time of a large job is never more than 100 milliseconds. If the app is the only process besides the OS, by limiting memory usage to no more than 75% of available RAM in actual practice both the app and its data are paged out almost not at all. On a real-time OS this behavior would be guaranteed. On MS Windows it is close enough. Linux probably does not do worse than Windows in this regard. > 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 I am rewriting it to require very little OS specific code. About the only thing that I will have to change is the way that PNG files are read into memory. I will have to switch to LibPNG. All of the MFC code is only development code and will not be part of production. > rewrite it to be platform-independent and possibly even > GUI-free, and your unrealistic The web service needs no GUI. It is all PNG in, and UTF-8 out. > 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 All that I know for sure is that some of my fundamental requirements are immutable. Some of Hector's advice seemed to continue to ignore these requirements. I was envisioning the web service as a single application. This may not have been the way that he was envisioning it. > >> >> > 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:24 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23KTDl6XxKHA.3564(a)TK2MSFTNGP05.phx.gbl... > 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? It is an HTML web page, BrowseFile widget. > > 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? That is what I am using. > > As mention many times, you can use standard HTTP or you > can design proprierty client/server tools. > I just decided this morning that the fundamental user interface will be a webpage with a BrowseForFile Button. > 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? I am using your first suggestion, (HTML) I got this suggestion from the JavaScript / Java groups. > > 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 Maybe this is simpler, but it the HTML Button is already sending the data in CGI format, wouldn't FastCGI be simpler?
From: Joseph M. Newcomer on 16 Mar 2010 23:36 See below... On Tue, 16 Mar 2010 19:50:03 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:e7e1pVWxKHA.948(a)TK2MSFTNGP05.phx.gbl... >> 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. > ><sarcasm> >Ah so I can load 4 GB of data from disk in less than a >millisecond, great then I will go with regular CGI. ></sarcasm> **** Really? A 10,000 RPM hard drive holds s small number of K bytes per track, and a track takes 0.0001 seconds to pass under the read heads. That's 0.1 ms per track; so under minimum fragmentation you can read maybe 5 or 10 tracks without a seek 9this is based onhow many surfaces the drive has, which is typically 5-10), and a seek usually takes aboutg 7-8ms, so I find it less than believable that you can load 4GB in 1ms; the disk simply cannot deliver data at that rate! **** \> >Each transaction will only take a few milliseconds iff (if >and only if) the 4 GB DFA is already loaded into memory. If >I have to load it every time, then each transaction will >take infeasibly long. **** You are once more assuming that you have a clue that modern Web servers still have the same performance problems they had a decade ago. Hector says it ain't so, and since he is closer to the technology than I am, I tend to believe him. For example, does the phrase "process pool" convey meaning to you? joe **** > >> >> 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 > 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:40
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:r9h0q55c6oml5fhpkrcfs2jtbsof7rf1ld(a)4ax.com... > 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. So if you really want to get nitpicky it is held in virtual memory (from the developer's point of view) that is mapped to RAM, if there is no reason to page it out. Which essentially boils down to it is held in RAM. (Even though it can theoretically be paged out at any time, in actual practice this rarely occurs if you have enough RAM. Virtual Memory is an abstraction of RAM that can at times be ignored. > > > 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. Not in the case of FastCGI, FastCGI does not use environment variables. > 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 That is logically entailed by the statement that the app does not terminate at the end of the request. With enough RAM and few processes running one can virtually ignore virtual memory. It may not be this way in theory, but, I know that it is this way in practice, because in practice I achieve the performance that could not be otherwise achieved. > 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 I think that you may be getting just a little bit too disrespectful. I do however really appreciate the support that you provided on the quality of my patent. > 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 |