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 17 Mar 2010 17:33 See below... On Tue, 16 Mar 2010 22:54:10 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:08i0q513cr5paa3m0mkvlmaoecd9vu7oqu(a)4ax.com... >> 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 > >In actual practice operating systems typically do not page >out code or data unless they need room for something else. >This will be the only application on the dedicated server, >thus little reason to be paged out. If necessary I will run >a very tiny little background process that forces the app to >do something once in a while. *** In acutal practice, they DO page out out code or data "just in case", in fact, Windows has done this for years. So don't cite fictitious "actual practice" as your rationale. I'd ask a linux expert what linux does before presuming I knew what it did. In the history of operating systems, I've work on four (including WIndows) that paged out idle process pages on the general principle that if the process isn't being used, it shouldn't be taking up any space. So I'm curious where you learned aobut "actual practice" and why you believe this must be true. Unix was one of the three systems I used that did this, and VMS was another IBM's TSS/360 was the fourth. so my "actual practice" on real operating systems says the opposite of your concept of "actual practice", and I'm curious what OS you used that worked this way. And why you think you can generalize from one instance of one OS to believe that all operating systems must follow this pattern. 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 > 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 17 Mar 2010 19:09 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OFqlachxKHA.2012(a)TK2MSFTNGP04.phx.gbl... > Hector Santos wrote: > >> For your web server, the summary basic PCI compliance >> items are: >> >> - SSL3, TLSv1 not SSL2 >> - 2048 bit cipers >> - Secured database locations >> - FIPS compliant Passwords encryption >> - PCI Compliant Authentication (HTTPS, with NONCE >> compliance) >> - PCI Session Management >> - Must have a logoff button >> - X minutes timeouts (5-15 mins) >> - NONCE credentials (can only be used once) >> >> OPENSSL (which mongoose supports) will handle the >> SSL/Ciphers for you. For the other items, the web server >> has to implement it. High end application servers (like >> Wildcat!) generally support PCI out of the box. >> >> In short, that mongoose authentication.c example is too >> simple. You would have to update it for secured PCI >> compliant authentication and session management. HTTPS >> (SSL) is not enough. > > Correction: > > SSL + HTTP-AUTH DIGEST W/ NONCE EXTENSION SUPPORT > > is the minimum allowed for PCI compliance. > > In other words, as I mentioned before, there are two basic > kinds of authentication: > > - Standard HTTP AUTH, BASIC and DIGEST > - Non-Standard FORM+COOKIE based authentication > > The reasons for the latter is that it allows web sites: > > - to create pretty login forms > - offer a logout button > > With standard HTTP AUTH, this is the browser popping up a > login window which web sites have no control over its look > and feel. The 2nd issue is that the RFC specifications > have no concept of a LOGOFF with HTTP AUTH. > > However, proprietary methods augmenting special cookies > with HTTP AUTH allows the web server to invalidate > (release) the HTTP AUTH browser credentials making it > possible, and it works very nicely, to offer a Logoff > button for HTTP AUTH as well. > > HTTP-AUTH BASIC is a plain text login method. DIGEST adds > SHA1 encryption. DIGEST comes with an optional NONCE > feature that for PCI must be supported. NONCE basically > makes each transaction credentials unique so that no two > authentications or session can be replayed or duplicated. > > -- > HLS They will be paying me through Paypal. Paypal will update a database that mongoose has access to. mongoose can decrement the balance.
From: Peter Olcott on 17 Mar 2010 19:13 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:soh2q5dglai3e7440iltlj0324npra8ger(a)4ax.com... > See below... > On Tue, 16 Mar 2010 22:01:22 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"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? >> > **** > Because you have noplace to put it! You can't use more > than 2GB address space in a > Windows app (I've sent a question off to my linux-expert > friend to see how much address I have used 4000 MB of space under windows many times. It seems like you may be continuing to insist upon factually incorrect informatuion. > space you get under linux; a question you should have > asked somewhere along the line and > known the answer to). Mapped files also exist in linux, > but the details are not known to > me. BUt there is no way in this universe you are going to > be able to read 4FB of data > into a WIn32 app running in any environment. Now, a > 64-bit native app is a completely > different question, and in that environment it is trivial. > joe I don't want the conversion cost and the cost of 64-bit pointers right now. I am already doing 4000+ MB, which is close enough for the foreseeable future. > **** > 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 17 Mar 2010 19:14 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:e7zU$hhxKHA.5576(a)TK2MSFTNGP05.phx.gbl... > BTW, it appears mongoose.c supports HTTP-AUTH DIGEST with > NONCE support so you could immediately use this for PCI > authentication and session management. However, you might > not have a working LOGOFF button that will work without a > cookie based concept added. That is not part of the HTTP > AUTH specification. > That is great thanks for the research and all of your valuable advice. I think that I am in the ballpark of the right track now. > -- > > Hector Santos wrote: > >> Hector Santos wrote: >> >>> For your web server, the summary basic PCI compliance >>> items are: >>> >>> - SSL3, TLSv1 not SSL2 >>> - 2048 bit cipers >>> - Secured database locations >>> - FIPS compliant Passwords encryption >>> - PCI Compliant Authentication (HTTPS, with NONCE >>> compliance) >>> - PCI Session Management >>> - Must have a logoff button >>> - X minutes timeouts (5-15 mins) >>> - NONCE credentials (can only be used once) >>> >>> OPENSSL (which mongoose supports) will handle the >>> SSL/Ciphers for you. For the other items, the web server >>> has to implement it. High end application servers (like >>> Wildcat!) generally support PCI out of the box. >>> >>> In short, that mongoose authentication.c example is too >>> simple. You would have to update it for secured PCI >>> compliant authentication and session management. HTTPS >>> (SSL) is not enough. >> >> Correction: >> >> SSL + HTTP-AUTH DIGEST W/ NONCE EXTENSION SUPPORT >> >> is the minimum allowed for PCI compliance. >> >> In other words, as I mentioned before, there are two >> basic kinds of authentication: >> >> - Standard HTTP AUTH, BASIC and DIGEST >> - Non-Standard FORM+COOKIE based authentication >> >> The reasons for the latter is that it allows web sites: >> >> - to create pretty login forms >> - offer a logout button >> >> With standard HTTP AUTH, this is the browser popping up a >> login window which web sites have no control over its >> look and feel. The 2nd issue is that the RFC >> specifications have no concept of a LOGOFF with HTTP >> AUTH. >> >> However, proprietary methods augmenting special cookies >> with HTTP AUTH allows the web server to invalidate >> (release) the HTTP AUTH browser credentials making it >> possible, and it works very nicely, to offer a Logoff >> button for HTTP AUTH as well. >> >> HTTP-AUTH BASIC is a plain text login method. DIGEST >> adds SHA1 encryption. DIGEST comes with an optional >> NONCE feature that for PCI must be supported. NONCE >> basically makes each transaction credentials unique so >> that no two authentications or session can be replayed or >> duplicated. >> > > > > -- > HLS
From: Peter Olcott on 17 Mar 2010 19:18
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:47i2q5tch6oigbaqllh9lk0942mp5pnkt0(a)4ax.com... > See below... > On Tue, 16 Mar 2010 22:54:10 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:08i0q513cr5paa3m0mkvlmaoecd9vu7oqu(a)4ax.com... >>> 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 >> >>In actual practice operating systems typically do not page >>out code or data unless they need room for something else. >>This will be the only application on the dedicated server, >>thus little reason to be paged out. If necessary I will >>run >>a very tiny little background process that forces the app >>to >>do something once in a while. > *** > In acutal practice, they DO page out out code or data > "just in case", in fact, Windows has > done this for years. So don't cite fictitious "actual > practice" as your rationale. I'd > ask a linux expert what linux does before presuming I knew > what it did. In the history of > operating systems, I've work on four (including WIndows) > that paged out idle process pages > on the general principle that if the process isn't being > used, it shouldn't be taking up > any space. So I'm curious where you learned aobut "actual > practice" and why you believe > this must be true. Unix was one of the three systems I > used that did this, and VMS was > another IBM's TSS/360 was the fourth. so my "actual > practice" on real operating systems > says the opposite of your concept of "actual practice", > and I'm curious what OS you used > that worked this way. And why you think you can > generalize from one instance of one OS to > believe that all operating systems must follow this > pattern. > joe Like I already said (in a message that you have not gotten to yet) I can always force it to add up all of its pixels every once in a while. For example whenever it is otherwise idle. This would require read access to every memory location, thus keeping pages paged in. > **** >> > >>> >>> ***** >>>> >>>>> >>>>> 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 >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |