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:

Searchable WebCat (etc.) Docs ? (1997) HTML Editors (1997) [WebDNA] fastcgi 7+ & [cart]? (2010) can WC render sites out? (1997) WebTen and WebCat (1997) limitation found on group searching (1997) access denied problem (1997) Duplicate Items in the Cart (1998) Great product and great job ! (1997) 4.0 upgrade and existing webMerchant (2000) Free Authorize.net (2004) WC 2.0 frames feature (1997) Oops... (2003) Inventory Control (2000) interesting ------ FW: Change to 5.0 per website licensing (2003) Erotic Sites (1997) Mailing Labels (2005) Some ThankYou page problems (1997) POST Datamissing? (1998) TXT (2003)