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 19 Mar 2010 17:54 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:O0MJi06xKHA.5940(a)TK2MSFTNGP02.phx.gbl... > 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. Not enough to make a difference thus moot. There was 21,000 page faults while loading the data, and the next day there was still 21,000 page faults. It might have been 21,000 + 5. Its proven to be moot so that is the extent of the detail that I need. > >> 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? It won't scale this way at all, I tested it and it fails to scale this way. This is not an issue if each instance takes 10 milliseconds or less to complete. I simply process a FIFO queue. If someone gives me a really big legitimate job, this job may get lower priority and be placed into a lower priority queue, still in FIFO order. > > -- > HLS
From: Hector Santos on 19 Mar 2010 17:54 Peter Olcott 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? The HTTP client will send the type in the HTTP request BODY block: Content-type: image/png > Using HTTP is it possible to reject a file that is too large > before very much of this file is sent? The HTTP request will have a HTTP request header: Content-length: But that length is the entire HTTP body following the request header block, i.e. you can send two or more uploads. You can use this length for a rough value, but to get the actual image size you need to parse the HTTP BODY to get the type and size. Note: Not all browsers will send a size in the body block, like if its only 1 image. Therefore you use the top HTTP request block Content-Length: header. -- HLS
From: Peter Olcott on 19 Mar 2010 18:20 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23s1kB76xKHA.4240(a)TK2MSFTNGP06.phx.gbl... > Peter Olcott 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? > > > The HTTP client will send the type in the HTTP request > BODY block: > > Content-type: image/png > >> Using HTTP is it possible to reject a file that is too >> large before very much of this file is sent? > > > The HTTP request will have a HTTP request header: > > Content-length: > > But that length is the entire HTTP body following the > request header block, i.e. you can send two or more > uploads. You can use this length for a rough value, but > to get the actual image size you need to parse the HTTP > BODY to get the type and size. > > Note: Not all browsers will send a size in the body block, > like if its only 1 image. Therefore you use the top HTTP > request block Content-Length: header. > > > -- > HLS OK great is this before or after my bandwidth quota has been hit with the full data load? In other words could a lower level protocol such as TCP/IP send a large portion of the file before my HTTP gets a chance to reject it because it is "denial of service attack" size? Alternatively could I somehow structure my code so that I only get just the bytes indicating the size and reject all other data before eating up any more of my bandwidth quota? example I only see these bytes---->"size(1000000000)" and reject the file before any additional bytes hit my bandwidth quota. NOTE the only valid data sent to my web application will be a single 24-bit PNG file that can vary in size up to a predetermined limit of something like 10K.
From: Hector Santos on 19 Mar 2010 18:38 Peter Olcott Asked: > 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. You will get the size (Content-Length:) of the HTTP request body from the HTTP request header block. You can issue an error at that point after receiving the header and before receiving the body. This is described in HTTP 1.1 standard RFC 2068, section 8.2 Message Transmission Requirements: http://www.ietf.org/rfc/rfc2068.txt This is a feature of a HTTP 1.1 server, not HTTP 1.0 server which generally requires the entire payload to be received first. You HTTP 1.1 web server needs to do this very carefully, otherwise it can cause resends by the clients. > 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. Only HTTP 1.1 clients will gracefully support a mid-stream reject by the web server. Otherwise, resends can occur. In other words, if the client is using HTTP 1.0, you will see that in the first line of the HTTP request header block, you could either reject the usage of this client or ignore the fact the user will see irregular "disconnected" error pages. -- HLS
From: Peter Olcott on 19 Mar 2010 20:21
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OdDHnT7xKHA.5480(a)TK2MSFTNGP06.phx.gbl... > Peter Olcott Asked: > >> 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. > > > You will get the size (Content-Length:) of the HTTP > request body from the HTTP request header block. > > You can issue an error at that point after receiving the > header and before receiving the body. This is described > in HTTP 1.1 standard This also includes all lower levels (TCP/IP, et cetera) of any data transmitted over HTTP? I imagine that there could be an underlying buffer that another lower level protocol uses, such that when HTTP sees the first 20 bytes, this lower level protocol has already eaten up 100K of my bandwidth quota. > RFC 2068, section 8.2 Message Transmission Requirements: > > http://www.ietf.org/rfc/rfc2068.txt > > This is a feature of a HTTP 1.1 server, not HTTP 1.0 > server which generally requires the entire payload to be > received first. > > You HTTP 1.1 web server needs to do this very carefully, > otherwise it can cause resends by the clients. > >> 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. > > > Only HTTP 1.1 clients will gracefully support a mid-stream > reject by the web server. Otherwise, resends can occur. > > In other words, if the client is using HTTP 1.0, you will > see that in the first line of the HTTP request header > block, you could either reject the usage of this client or > ignore the fact the user will see irregular "disconnected" > error pages. > > -- > HLS Since HTTP 1.1 has been around for 14 years I may simply reject all HTTP 1.0 calls and request the user update to a newer browser. Or I could force the user to use some sort of java applet that sends the data using the HTTP 1.1 format. This client side code could also verify the size and type of the file (specifically 24-bit PNG) before anything is sent. It could also provide a file search dialogbox that only looks for PNG files. With this scenario I would no longer be limited to HTTP, I could devise my own protocol that could strip off some of the extra HTTP baggage. Would I be back to sockets again if I did this? Would this be programming at the TCP/IP level or some other level? |