Re: [Dynapi-Help] Simple communication questions...

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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,
> > >>I was testing on an
> > >>Apache server and the script would not work unless
> > >>the filename began with
> > >>"nph-" which stands for non-parsed headers.
> > >>
> > >>=============================
> > >>BEGIN - Perl script
> > >>=============================
> > >>#! /usr/bin/perl -w
> > >>use strict;
> > >>
> > >>use CGI qw/:standard :push/;
> > >>use CGI::Carp 'fatalsToBrowser';
> > >>
> > >>$CGI::POST_MAX = 1024 * 1024; # max 1M posts
> > >>$CGI::DISABLE_UPLOADS = 1;  # no uploads
> > >>$| = 1;
> > >>
> > >>print multipart_init(-boundary=>'----here we
> > go!');
> > >>
> > >>foreach (0 .. 4) {
> > >>    print multipart_start(-type=>'text/plain'),
> > >>          "The current time is
> > >>",scalar(localtime),"\n";
> > >>    if ($_ < 4) {
> > >>            print multipart_end;
> > >>    } else {
> > >>            print multipart_final;
> > >>    }
> > >>    sleep 1;
> > >>}
> > >>
> > >>=============================
> > >>END - Perl script
> > >>=============================
> > >>
> > >>As you can see, most of the actual server-push
> > code
> > >>is handled by the CGI
> > >>Perl Module.  So just taking a quick peek inside
> > to
> > >>show the relevent bits
> > >>of raw HTTP and HTML tricks used, or just using
> > >>telnet or wget to fetch from
> > >>the server.
> > >>
> > >>Headers: (first three added by Apache, last one
> > >>added by the script)
> > >>
> > >>HTTP/1.0 200 OK
> > >>Server: Apache/2.0.47 (Unix) mod_ssl/2.0.47
> > >>OpenSSL/0.9.7c DAV/2
> > >>PHP/4.3.4RC1
> > >>Date: Tue, 14 Oct 2003 13:39:48 GMT
> > >>Content-Type:
> > >>multipart/x-mixed-replace;boundary="----here we
> > go!"
> > >>
> > >>Content:
> > >>
> > >>WARNING: YOUR BROWSER DOESN'T SUPPORT THIS
> > >>SERVER-PUSH TECHNOLOGY.
> > >>------here we go!
> > >>Content-Type: text/plain
> > >>
> > >>The current time is Tue Oct 14 09:39:48 2003
> > >>
> > >>------here we go!
> > >>Content-Type: text/plain
> > >>
> > >>The current time is Tue Oct 14 09:39:49 2003
> > >>
> > >>------here we go!
> > >>Content-Type: text/plain
> > >>
> > >>The current time is Tue Oct 14 09:39:50 2003
> > >>
> > >>------here we go!
> > >>Content-Type: text/plain
> > >>
> > >>The current time is Tue Oct 14 09:39:51 2003
> > >>
> > >>------here we go!
> > >>Content-Type: text/plain
> > >>
> > >>The current time is Tue Oct 14 09:39:52 2003
> > >>
> > >>------here we go!--
> > >>WARNING: YOUR BROWSER DOESN'T SUPPORT THIS
> > >>SERVER-PUSH TECHNOLOGY.
> > >>
> > >>
> > >>
> > >>----- Original Message ----- 
> > >>From: "Raymond Irving" <xw...@ya...>
> > >>To: <dyn...@li...>
> > >>Sent: Monday, October 13, 2003 10:27 AM
> > >>Subject: Re: [Dynapi-Help] Simple communication
> > >>questions...
> > >>
> > >>
> > >>
> > >>>See below:
> > >>>
> > >>>--- Clemens Eisserer <Lin...@we...> wrote:
> > >>>
> > >>>>Hi again!
> > >>>>
> > >>>>I´m currently thinking about writing a simple
> > >>>>JS-Chat, so that the chat doent need to reload
> > >>>>always when
> > >>>>new messages recieve.
> > >>>>The problem is, that the server should connect
> > >>
> > >>to
> > >>
> > >>>>the client, which is not possible as far as I
> > >>
> > >>know,
> > >>
> > >>>>this
> > >>>>means the client has to use possling and aks all
> > >>
> > >>x
> > >>
> > >>>>seconds the server for new messages.
> > >>>>
> > >>>>1.) Is there no other was to do this than
> > >>
> > >>polling?
> > >>
> > >>>Not that I know of
> > >>>
> > >>>
> > >>>>2.) These are the only polling-ideas I had:
> > >>>>* Blocking soda-rpc function. Blocks till
> > >>
> > >>messages
> > >>
> > >>>>are on server. (Problem with blocking - no
> > >>
> > >>events
> > >>
> > >>>>etc?)
> > >>>>* Non-Blocking soda-rpc function. Returns -1 if
> > >>>>nothing is there...
> > >>>>
> > >>>>Is the blocking version possible, or will it
> > >>
> > >>cause
> > >>
> > >>>>the application to hand in the poll-loop. This
> >
> === 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
> Dyn...@li...
> https://lists.sourceforge.net/lists/listinfo/dynapi-help
>
>