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 19 Mar 2010 17:25 See below... On Thu, 18 Mar 2010 13:33:43 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >It looks like I am going to be using HTTP as the protocol. I >just bought two books on it. I am estimating that the TCP/IP >is mostly invisible at the HTTP layer. I am using the HTTP >protocol because it seems that the HTML element that I am >using, sends the data using this protocol. > <input name="userfile" type="file" accept="image/png" /> > >Using HTTP is it possible to reject a file that is the wrong >format before the entire file is sent? >Using HTTP is it possible to reject a file that is too large >before very much of this file is sent? >One way or another (the least effort way) I will be able to >make sure that my data remains (at least mostly) in physical >RAM. I will address this later on, since this is merely an >implementation detail. I always proceed with development >using a strict hierarchy of increasing specificity. It is >best to go this way because many of these details often >become moot before final design is complete **** As far as I know, if you tell HTML client-side that a particular file is PNG format it trusts you and sends it as a PNG file. If it isn't, the server side is going to have to deal with that. Of course, this may be implementation-specific to a particular browser. joe .. > >>> >> 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 19 Mar 2010 17:33 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:p7q7q5lhaahjv9ksf3llqg18nsil8gondv(a)4ax.com... > The measured different is not signficant. That'saoubt > 0.5%. I expect to see typical > values that different by 5% between any two measurements. > 0.02 minutes out of 3.75 is not > statistically signficant. if you measure a dozen > instances or more and tell me the mean > and standard deviation then you have something worth > talking about. > joe > (I regularly give a lecture on how to do performance > measurement, and your technique of > generalizing from two samples with minute differences is > not scientifically sound) > *** > Yes I knew that, yet, the fact that it was measured as faster would seem to provide completely sufficient evidence that it is not at all slower. On a real-time OS the issue would be different. In this case a difference in performance would indicate a bug. > On Fri, 19 Mar 2010 12:49:01 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>message >>news:%23CzP5d4xKHA.4492(a)TK2MSFTNGP05.phx.gbl... >>> >>> Peter Olcott wrote: >>> >>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>> message news:ea82ZB4xKHA.3304(a)TK2MSFTNGP06.phx.gbl... >>>>> Peter Olcott wrote: >>>>> >>>>> >>>>>> I extended your half hour test to 10 hours and >>>>>> nothing >>>>>> was paged out on Windows 7 with 8.0 GB RAM. >>>>> >>>>> How do you know? What measurement counters did you >>>>> use? >>>>> And what is the application doing? >>>>> >>>>> -- >>>>> HLS >>>> >>>> I had windows report all of its paging, and the number >>>> did not grow when I re-invoked the DFA process again >>>> after ten idle hours. Also (weirdly enough) the >>>> performance was a fraction of a percent faster after >>>> ten >>>> hours of idleness. Execution time went from 3.75 >>>> minutes >>>> to 3.73 minutes. >>> >>> What were the following counters? >>> >>> - page fault >>> - context switching rate >>> - working set >>> >>> I'm more interested in the page faults. >>> >>> -- >>> HLS >> >>Yes there were no (or minimal) page faults after I invoked >>the process again after a ten hour wait. The crucial >>performance measure for me is that processing time did not >>increase at all after the ten hour delay. In fact it >>decreased from 3.75 minutes to 3.73 minutes. >> > 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 19 Mar 2010 17:35 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:chq7q5141nidmemdos1fj97ucs7c2ptek1(a)4ax.com... > See below... > On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:44i4q51iamfnidn7cji8mvft16if8u6jdl(a)4ax.com... >>> See below... >>> On Wed, 17 Mar 2010 14:01:22 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>> **** >>> Yes, going back to my comment, you are running on Win64, >>> which allows 4GB of user space, >>> which has to account for your heap, all your stacks if >>> multithreaded, your code, and all >>> your support code (various DLLs). I said you can't get >>> 4GB on Win32. You can get it >>> running a Win32 app on Win64. >>> joe >>> **** >> >>Yes and it also looks like converting to 64-bit will cost >>very little system resources. I was thinking that >>std::vector elements would increase in size by four bytes. >>With further consideration this would seem to not be the >>case. > **** > You would have to know the representation of your > std::vector elements. An element will > add 4 bytes for every 64-bit pointer in it. If there are > no pointers, the size would not > change unless you were using _PTR types for integers which > are 32 bits wide in 32-bit apps > and 64-bits wide in 64-bit apps. > joe > **** Since I have already written one std::vector, I could completely determine its internal structure. When I tried to remember my original design, I remembered that the elements do not need pointers, they are simply offsets into a single shared block of memory. >> >>>> >>>>> joe >>>>> 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 >> > 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 19 Mar 2010 17:43 Peter Olcott wrote: >> What were the following counters? >> >> - page fault >> - context switching rate >> - working set >> >> I'm more interested in the page faults. > Yes there were no (or minimal) page faults after I invoked > the process again after a ten hour wait. That suggest you do have paging occurring. > The crucial performance measure for me is that processing time > did not increase at all after the ten hour delay. In fact it > decreased from 3.75 minutes to 3.73 minutes. Unrealistic consideration. What happens when you have 2, 3, 4 or more instances going on? In other words, how will it scale as the load increases? -- HLS
From: Peter Olcott on 19 Mar 2010 17:46
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:cpq7q5dbueo4bee9225aioscqp3evsec0d(a)4ax.com... > See below... > On Thu, 18 Mar 2010 13:33:43 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >> >>It looks like I am going to be using HTTP as the protocol. >>I >>just bought two books on it. I am estimating that the >>TCP/IP >>is mostly invisible at the HTTP layer. I am using the HTTP >>protocol because it seems that the HTML element that I am >>using, sends the data using this protocol. >> <input name="userfile" type="file" accept="image/png" /> >> >>Using HTTP is it possible to reject a file that is the >>wrong >>format before the entire file is sent? >>Using HTTP is it possible to reject a file that is too >>large >>before very much of this file is sent? >>One way or another (the least effort way) I will be able >>to >>make sure that my data remains (at least mostly) in >>physical >>RAM. I will address this later on, since this is merely an >>implementation detail. I always proceed with development >>using a strict hierarchy of increasing specificity. It is >>best to go this way because many of these details often >>become moot before final design is complete > **** > As far as I know, if you tell HTML client-side that a > particular file is PNG format it > trusts you and sends it as a PNG file. If it isn't, the > server side is going to have to > deal with that. Of course, this may be > implementation-specific to a particular browser. > joe Yes but the crucial aspect of this question that you ignored is whether or not I can reject a file BEFORE I have paid for ALL of its bandwidth. If not then a simply denial of service attack could simply send huge files until my quota is used up. If you skip any part of this message, please do not skip this part. If I can not reject a file at the HTTP level, then I have to work at a lower level. In the ideal case I can receive the file size before any of the rest of the file is sent, and reject is with only a few bytes of wasted bandwidth. After I determine that the file is not too large I then get however many minimal bytes are required to determine the file type, and then reject the rest of the file if it is not 24-bit PNG. A lot of this risk could be mitigated by user authentication. Some of this risk could not be mitigated by user authentication because I want to provide a trial of my service for free. I could reduce this risk too by requiring user accounts even for my free customers. If they send a huge file, I cancel the account that it came from. > . >> >>>> >>> 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 |