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:20 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uuTi8cXxKHA.6020(a)TK2MSFTNGP06.phx.gbl... > 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 That may be the case, but, the term "memory map" is gibberish to me in this context. I envision my app reading in all of its data, and keeping it in std::vectors. Its going from disk to RAM. I see no need for any map.
From: Hector Santos on 16 Mar 2010 22:22 Peter Olcott wrote: >> 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? Socket drop events/detection. You have to be ready for it. > Another thing, I want to > immediately close the connection on the first packet if > anything besides a 24-bit PNG file is detected. shutdown(mySocketHandle,2) flush receiver buffer loop closesocket(mySocketHandle) > 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. What web server are you going to be using? > I have no idea what you are talking about when referring to > a memory map. Well you should be aware of these things around here. Other common terms are Memory Map File (MMF) or File Map http://en.wikipedia.org/wiki/Memory-mapped_file http://msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms810613.aspx > It is not a 4.0 GB file, it is numerous files > making up a total of 4.0 GB. So you open each one up as a MMF. If this is static meta data, then merged them into one. -- HLS
From: Hector Santos on 16 Mar 2010 22:28 Peter Olcott wrote: > That may be the case, but, the term "memory map" is > gibberish to me in this context. Look, you should of have the common respect that when people provide FREE assistance, that you do some leg work on your own and understand the points being made. > I envision my app reading > in all of its data, and keeping it in std::vectors. Its > going from disk to RAM. I see no need for any map. You WILL! You need a vector class that offer memory map file virtualization. No way to load up that under under 32 bit. Even you going 64 bit, you will see need to virtualize it. -- HLS
From: Joseph M. Newcomer on 16 Mar 2010 22:24 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) And you are making unrealisitic assumptions that massive programs will remain memory-resident, which is host-OS-specific behavior. 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. 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: Geoff on 16 Mar 2010 22:29
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. |