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 17 Mar 2010 16:04 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:43b2q51hukg9s1gofoqds7vodf0lcq4bhp(a)4ax.com... > See below... > On Tue, 16 Mar 2010 22:19:25 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"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. > **** > Depends. Did the end user configure for local DNS > caching? WHat was the cache retention > time set by the end user? Note, again, YOU HAVE NO > CONTROL OVER THESE PARAMETERS! > **** >> >>> 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. > ***** > No, we hear them, we just don't believe that FastCGI is > going to be the solution that will > solve every issue for you. Hector says that CGI has been > improved to where it has > comparable performance to FastCGI. I have no information > to confirm or deny that > statement. Again, you are not a server expert, so you > should pay attention to the server > expert. > **** >> >>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. > **** > I have no idea why you think this is true. This is not an > assumption I would have > considered valid until I talked to a linux expert (since > you will be hosted on linux). Yet > you make this assertion simply because you THINK it should > work, as opposed to getting > data that confirms that the OS actually works this way. > **** An OS that unloads any part of an executing process when it has no need for additional memory would be an idiotic OS. It would be flat out stupid to do this. I am not convinced that either Windows or Linux is this stupid. If this same OS unloads part of a process because the process has been idle for a long time, AND needs more memory to do some housekeeping task, then this case I could see a reason that would not be stupid. >> >>> 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. > **** > PNG files would not be "read into memory"; instead, you > will need to convert the input > string (however it is provided, most likely via stdin) to > a bitmap, and that requires a > library that does not read the PNG data from a file but > from a text stream. > **** YES, or if I have to write is to disk and read it back in again. Reading and writing 2K files will not kill me. >> >>> 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. > **** > OK, that's good. You *will* have to write the FastCGI > interface and make sure it works > multithreaded so it can handle multiple requests. I am going with Hectors idea of a tiny embedded webserver built in to my code. There are several freeware one's one of these looks good enogh for my needs: mongoose. > **** >> >>> 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. > **** > You can do it by writing a "front end" that exports a > known port and implements your > appliction-specific protocol to get the data to send to > your "business logic" component. > It doesn't solve the paging problem, or the 4GB problem. > joe I think that I will be going with some sort of application specific webserver such as mongoose. Hector tried to sell me on his webserver, but, it was too costly and not flexible enough for me right now. In the future when I scale up to multiple servers this may change. > > **** >> >>> >>>> >>>> > 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 >> > 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 17 Mar 2010 16:56 Peter Olcott wrote: > What is PCI? (I heard of PKI) I will be using Paypal as my > payment processor. PCI - Payment Card Industry. The industry, Visa/Mastercard, etc, go together and put together a set of guidelines for any electronic service vendor to help protect against credit card fraud, etc. There are PCI categories the each vendor fits in for which they must comply at some level otherwise a business, especially if public, won't get certified by their auditors, etc. 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. -- HLS
From: Hector Santos on 17 Mar 2010 17:16 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: Joseph M. Newcomer on 17 Mar 2010 17:21 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 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 **** 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 17 Mar 2010 17:26
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. -- 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 |