From: Raymond I. <xw...@ya...> - 2003-10-15 20:16:14
|
In the DynAPI design sockets or http connections are not held or opened in definately. They're opened only for short periods of time (e.g. 50 secs) then released and reopened a few seconds later. This makes it posible to use both Push and Pull techniques to balance the connection load. The user (server-side) will have the option to adjust and balance the system while having the choice of using either push, pull or both. -- Raymond Irving --- Leif W <war...@us...> wrote: > This looks very promising. I've skimmed through the > whitepaper and a couple > example sources but can't seem to find exactly what > HTTP headers they're > sending, or if they're not doing the multipart hack > which is netscape and > mozilla specific, but instead just constantly > streaming code to an open > socket which appears to be what they're doing. > > Just wanted to point out what I think is the main > disadvantage of this > design, and reiterate and elaborate upon that point > just so it's understood > and maybe either find some way to work around, or at > least make sure we pass > on the warning to developers who may use our > library. Using this technique > requires a socket to be constantly open between the > client and the server. > Normally, the browser makes a request, the socket is > used then released and > is free for the server to use to handle more > requests. But with this > technique, the sockets will be used directly > proportional to the number of > users using the push, plus the number of users > otherwise requesting > documents on the server. But most computers are > compiled with 65535 sockets > by default I believe. I am not sure if any > operating systems allow for this > number to be increased. I suspect that OSes like > Linux and FreeBSD would > allow this to be increased, by hacking the source > code. It may or may not > be as trivial as changing a C language #define. > However it is done, having > achieved the proper modification and documented it, > recompiling the kernel > source is usually trivial for admin that keep their > software generally > unmodified and up to date, and who don't rely solely > on rpm or dselect to > handle everything, but it may not be trivial if they > have heavily modified > sources, dependent on third party code, or something > bizarre. But be aware, > this may be in a shared hosting environment, or a > dedicated web server, may > be owned by the company that runs the hosting > provider, or by the company > that runs the web site. The usage of this on a > moderate to high-traffic > site hosted on a machine that is currently handling > all it's requests with > plenty of socket overhead may hit a a resource > limitation which could affect > the whole server, which could be undesirable, > especially in a shared hosting > environment. Also, there may be many levels of > management or ownership > between the web developer using this technique in > the DynAPI, and the admin > who would need to respond to the potential increased > resource requirements > if this technique were to be deployed on a > relatively high-traffic website. > Therefore I think it's imperative that we have some > sort of disclaimer on > the documentation page, and perhaps another page > with either notes to > increasing the number of sockets, or links to such > resources or something. > > Leif > > ----- Original Message ----- > From: "Raymond Irving" <xw...@ya...> > To: <dyn...@li...> > Sent: Wednesday, October 15, 2003 11:34 AM > Subject: Re: [Dynapi-Help] Simple communication > questions... > > > > > > Wow! > > > > I've spend serveral hours looking into the > push/pull > > (pushlet) solution and must say that I have > managed to > > get a working prototype of the server-side push > > feature. > > > > I think it's possible that dynapi will be able to > > support both Push and/or Pull functionality. It's > > still a far way off and requires a lot of time to > > think through the design of the system (only if I > had > > a full time dynapi job :) > > > > In short I think it will be as simple as adding an > > event listener to a dynobject: > > > > io.addEventListener({ > > onserver_someventhere : function(e,s) { > > // some code here > > }, > > onserver_anothereventhere : function(e,s) { > > // some code here > > } > > }); > > > > With this technology we could use ioelement with > any > > webserver or server-side language to implement the > > push and/or pull requests > > > > With the push method the client is notified > whenever > > the server invokes or raises an event: > > > > ws_invokeEvent('someeventhere') > > ... > > ws_invokeEvent('anothereventhere') > > > > > > The Push/Pull technique should work with all > supported > > web browsers. The API will handle all the > technical > > details so the user only have to listen in for an > > event from the server. > > > > What do you think? > > > > > > -- > > Raymond Irving > > > > > > > > --- Andrew Gillett <an...@zo...> wrote: > > > This may be a little off-topic, but another > > > interesting site that's worth a look at is > > > www.pushlets.com. Their basic setup is to use a > > > Java servlet to push javascript down a HTTP > > > connection to a hidden frame. And they have > some > > > impressive demos :) The claim compatability > with IE > > > (back to 4.01) and Netscape (back to 4.05). > > > > > > It would be _so impressive_ if an IOElement > could do > > > a similar thing.... > > > > > > > > > Andrew Gillett > > > > > > > > > Raymond Irving wrote: > > > > Hi, > > > > > > > > For some more information on server-push and > > > > client-pull visit the following website: > > > > > > > > > > > > > > http://wp.netscape.com/assist/net_sites/pushpull.html > > > > > > > > -- > > > > Raymond Irving > > > > > > > > --- Leif W <war...@us...> wrote: > > > > > > > >>I was thinking of how to approach this problem > a > > > >>while back (for the case of > > > >>a simple online cardgame) but never came to > > > anything > > > >>concrete. However, I > > > >>did remember playing with some script (it was > in > > > >>Perl but you could use any > > > >>language) which acts as a server-push, but it > only > > > >>works for Mozilla, not > > > >>IE, and not tested in Opera or Safari. So, if > you > > > >>want a true client-server > > > >>model with bidirectional communication I guess > > > >>you're best off coding a Java > > > >>applet for the browser, and whatever language > > > >>specialized server with your > > > >>own protocol. > > > >> > > > >>Anyways here's the example code I was using. > > > Also, > === message truncated === __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |