Re: [WebDNA] HTTP Streaming - POSSIBLE!

This WebDNA talk-list message is from

2010


It keeps the original formatting.
numero = 105573
interpreted = N
texte = Let's say a folder is created for each auction item. Then every time a new bid comes in it writes a new sequential file. Now when a new bidder views a potential item it would search the number of files in that auctions directory and would keep the connection open with a waitforfile command until a new bid comes in. Then when the file is created it simply refreshed the page and waits for the next bid sequential file. This solves your server load issues because it doesn't demand packets to constantly be exchanged. Each client reloads once, and only when a new bid is created. A pure WEBDNA solutions... Sounds simple, perhaps I'm not understanding the dilemma or problem... Sincerely, Scott Walters scott@ideassoftware.com On Jul 12, 2010, at 6:22 PM, Kenneth Grome wrote: >> Which included a script that reloaded itself >> upon the creation of the next sequential file. > > I already have a mockup of my auction site working with a simple > meta-refresh in an iframe, so I don't see how your approach is going > to solve any problems for me. > > The problems I am anticipating are latency and overhead. Maybe I > can get rid of some of that with XMLHTTPRequest, but I don't think > it's going to help much, because even though Javascript can be > programmed to open a new server connection via XMLHTTPRequest as > soon as the last one closes, the browser still has to repetitively > open and close these connections -- every second or two at a minimum > if I'm hoping to keep the browsers updated with the most recent bid > price. > > Unfortunately this polling must be initiated by the browser, not by > the server, and this means as many as a couple thousand connections > per second -- just to CHECK to see if the data has been updated. If > the data has not been updated then it's a wasted connection because > the connection still has to be opened, then the current data sent > (again), then the connection closed. > > A better alternative might be to "keep the connection open" and send > each update to the browser as it happens, over the same open > connection. This gets rid of the latency inherent in polling once > each second because the data gets sent immediately instead of > waiting to be sent upon the next polling request ... and it gets rid > of most of the overhead inherent in building up and tearing down all > those connections. > > Unfortunately webdna is not appropriate for this type of > application, so I've come up with a work-around meta-refresh / > iframe technique as a possible alternative. It's not the best > alternative, that's for sure, but it's a potential solution that I > can understand. I only hope that webdna is fast enough to respond > to all those connections. > > Or I hope to find a better alternative ... > > Sincerely, > Kenneth Grome > > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Kenneth Grome 2010)
  2. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Scott Walters 2010)
  3. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Kenneth Grome 2010)
  4. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Kenneth Grome 2010)
  5. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Scott Walters 2010)
  6. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Christer Olsson 2010)
  7. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Kenneth Grome 2010)
  8. RE: [WebDNA] HTTP Streaming - POSSIBLE! ("Olin Lagon" 2010)
  9. Re: [WebDNA] HTTP Streaming - POSSIBLE! (Scott Walters 2010)
Let's say a folder is created for each auction item. Then every time a new bid comes in it writes a new sequential file. Now when a new bidder views a potential item it would search the number of files in that auctions directory and would keep the connection open with a waitforfile command until a new bid comes in. Then when the file is created it simply refreshed the page and waits for the next bid sequential file. This solves your server load issues because it doesn't demand packets to constantly be exchanged. Each client reloads once, and only when a new bid is created. A pure WEBDNA solutions... Sounds simple, perhaps I'm not understanding the dilemma or problem... Sincerely, Scott Walters scott@ideassoftware.com On Jul 12, 2010, at 6:22 PM, Kenneth Grome wrote: >> Which included a script that reloaded itself >> upon the creation of the next sequential file. > > I already have a mockup of my auction site working with a simple > meta-refresh in an iframe, so I don't see how your approach is going > to solve any problems for me. > > The problems I am anticipating are latency and overhead. Maybe I > can get rid of some of that with XMLHTTPRequest, but I don't think > it's going to help much, because even though Javascript can be > programmed to open a new server connection via XMLHTTPRequest as > soon as the last one closes, the browser still has to repetitively > open and close these connections -- every second or two at a minimum > if I'm hoping to keep the browsers updated with the most recent bid > price. > > Unfortunately this polling must be initiated by the browser, not by > the server, and this means as many as a couple thousand connections > per second -- just to CHECK to see if the data has been updated. If > the data has not been updated then it's a wasted connection because > the connection still has to be opened, then the current data sent > (again), then the connection closed. > > A better alternative might be to "keep the connection open" and send > each update to the browser as it happens, over the same open > connection. This gets rid of the latency inherent in polling once > each second because the data gets sent immediately instead of > waiting to be sent upon the next polling request ... and it gets rid > of most of the overhead inherent in building up and tearing down all > those connections. > > Unfortunately webdna is not appropriate for this type of > application, so I've come up with a work-around meta-refresh / > iframe technique as a possible alternative. It's not the best > alternative, that's for sure, but it's a potential solution that I > can understand. I only hope that webdna is fast enough to respond > to all those connections. > > Or I hope to find a better alternative ... > > Sincerely, > Kenneth Grome > > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > Scott Walters

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Field Totals (2004) WebCatalog2 Feature Feedback (1996) select multiple 2 more cents (1997) Great product and great job ! (1997) Shopping carts and reloading pages (1997) Severe Slowness (2005) WebCat2 several catalogs? (1997) WebDNA on Windows questions (2007) [WebDNA] Test - no messages since 9th of June 2009. (2009) Apache 2.0 incompatible? (2005) [OT] XML data to tab delimited database (2003) Emailer choke (1997) Does TCPconnect/TCPsend do multiples? (2000) [TaxableTotal] - not working with AOL and IE (1997) Grouping search fields, etc. (1997) New Installation (1998) transferring values (1998) Credit card processing - UK (1997) WebCatalog 2.0 b 15 mac (1997) shipcost (1997)