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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dynapi-help

Reply via email to