Multiple clients

Hey all,
I am a little confused about the cometd protocol. Firstly,
when I run
my server and client side browser (using Firebug), I can see
that there
is a long-polling connection on channel
"/meta/reconnect". This seems
to return every 45 seconds (with no errors) before a new
post is
started. Is this what should happen???

Secondly, I set up another channels to communicate with the
server. The
client and server are signed up to the channel so both
receive the
messages (the client gets an echo). This all works well
(with a second
post sent and almost instantly returning with the message).
However,
when there are multiple clients subscribed to the channel
(in different
browser instances), a new POST is started, however, there is
no
response from the server until the gap when the
"/meta/reconnect"
channel Post returns and is restarted. I thought this might
be because
I was using Tomcat with weird library hacks, but now I am
using Jetty
and the problem persists. With a client and server
subscribed to the
channel, it is fine... when there are multiple clients, it
breaks
down... Can anyone shed any light on this???

Thanks,

Will


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-users" group.
To post to this group, send email to cometd-usersgooglegroups.com
To unsubscribe from this group, send email to
cometd-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/cometd-users

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

For this reason we implemented some IPC-over-cookies hackery
in the 
mod_pubsub client. We could revive that, but it may
significantly 
increase the complexity of the client.

There's also discussion of how to handle this in the
OpenAjax working 
groups (thanks to Greg Wilkins), but at the end of the day
we need some 
relief from the browser vendors before this is going to get 
demonstrably better.

Regards

On Thursday 21 December 2006 12:46 pm, Mark Smith wrote:
> > when there are multiple clients, it breaks
> > down... Can anyone shed any light on this???
>
> If you're trying to do it with the same browser in
different tabs
> then you won't be able to.  Browsers tend to only allow
N outstanding
> connections to the server - less than you need to run
"multiple
> clients".  Open up Firefox and also open up IE and
start a client in
> each - then it should work.

-- 
Alex Russell
alexsitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158
FFDF 2894 6876
alexdojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78
E242 59C3 9723

Thanks for the quick reply (and sorry for the multiple
posts- my first
one didn't appear for hours, so I reposted!).

I was stuck on this issue for ages... It makes it a little
more tricky
to test, as I usually like to get it up and running in one
browser, and
then extend the functionality to another (for my web app).
It would be
nice if this could one day be resolved, as it would make
development
more straight forward. For now, is there any hack I can
apply, to run
the web application from two instances of firefox - or do I
need to use
two different machines?

Thanks again,

Will


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-users" group.
To post to this group, send email to cometd-usersgooglegroups.com
To unsubscribe from this group, send email to
cometd-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/cometd-users

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

On Friday 22 December 2006 4:20 am, Chris Barber wrote:
> So, I'm curious about the cookie hackery.  Thinking out
loud... with
> a cookie, you could block other windows from connecting
to the same
> comet server which appears to be what Renkoo does. 
What if you had a
> unique cookie for each window (i.e. cometd24901,
cometd59159, etc),
> then one of the windows would be the designated window
for
> communicating with the comet server. 

That's exactly right. At some point, in order to make the
communication 
high bandwidth enough, you need a handle to the other
windows which can 
be accomplished by creating an iframe per window and having
each of the 
other windows try to open() based on the name you specify
for that 
iframe. From there, you can say something like:

	var otherCometdRef = iframeRef.window.parent.cometd;

And you should be able to call methods on that reference.
The overhead 
involved (an iframe per "child" window) is
certainly better than hosing 
your connection entirely.

We might have other options now (like what you've got below)
now that 
dojo.storage can store more than 4K of data and share it
across browser 
instances (IPC over dojo.storage).

Regards

> Each window's unique cookie 
> would act as a proxy for piping messages.  I'd think
each window
> would have it's own clientId on the server.  To test
this cookie IPC
> stuff, I wrote the following:
>
> *Sender.html*
>
> <html>
> <head>
>     <title>IPC Sender</title>
>
>     <script type="text/javascript">
>     var djConfig = { isDebug:true };
>     </script>
>
>     <script src="/dojo/dojo.js"
type="text/javascript"></script>
>
>     <script type="text/javascript">
>     dojo.require("dojo.event.*");
>     dojo.require("dojo.io.cookie");
>
>     function send() {
>         var msgField =
dojo.byId("messageField");
>         var json = "{message:'" +
msgField.value + "'}";
>         dojo.io.cookie.setCookie("ipc",
json);
>         dojo.debug("Sent "" + json +
""");
>         msgField.value = "";
>         msgField.focus();
>     }
>
>     function checkKey(evt) {
>         if (evt.keyCode == 13) {
>             dojo.event.browser.stopEvent(evt);
>             send();
>         }
>     }
>
>     dojo.addOnLoad(function(){
>        
dojo.event.connect(dojo.byId("messageField"),
"onkeydown",
> checkKey);
>        
dojo.event.connect(dojo.byId("submitButton"),
"onclick",
> send); });
>     </script>
> </head>
> <body>
>
> <input id="messageField"
type="text" value="">
> <input id="submitButton"
type="submit" value="Send!">
>
> </body>
> </html>
>
> *Receiver.html*
>
> <html>
> <head>
>     <title>IPC Receiver</title>
>
>     <script type="text/javascript">
>     var djConfig = { isDebug:true };
>     </script>
>
>     <script src="/dojo/dojo.js"
type="text/javascript"></script>
>
>     <script type="text/javascript">
>     dojo.require("dojo.io.cookie");
>
>     function checkMessages() {
>         var c =
dojo.io.cookie.getCookie("ipc");
>         if (c) {
>            
dojo.io.cookie.deleteCookie("ipc");
>             var msg = eval("(" + c +
")");
>             dojo.debug("Received message
"" + msg.message + """);
>         }
>         setTimeout(checkMessages, 500);
>     }
>
>     dojo.addOnLoad(checkMessages);
>     </script>
> </head>
> <body></body>
> </html>
>
> You should easily be able to support a dozen windows
open at the same
> time.  The biggest problem is the 4KB limit, so a large
response
> would have to be chunked and reassembled.  Probably
would also be a
> good idea to only allow 2KB for storage and leave the
rest for other
> data.  Once a message has been read from the cookie, it
is removed so
> that the cookie size stays small and that it isn't sent
to the server
> when the next request is issued.  It might be a good
idea to set the
> cookie's domain to ".mydomain.com" too. 
There is also the minor
> issue of escaping chars too, but that's easy.  It's
kind of hacky
> that the receiver has to poll the cookie.  You could
tie the cookie
> poller to a dojo.event.topic so all your code has to do
is subscribe
> to it.
>
> Also, what about using dojo.storage for proxying data
between
> windows?
>
> I can see how this can get complex very quickly.  I'm
definitely
> going to look into this further.  I'm just now figuring
this out and
> I imagine someone else is years ahead of me.
>
> -Chris
>
> Alex Russell wrote:
> > For this reason we implemented some
IPC-over-cookies hackery in the
> > mod_pubsub client. We could revive that, but it
may significantly
> > increase the complexity of the client.
> >
> > There's also discussion of how to handle this in
the OpenAjax
> > working groups (thanks to Greg Wilkins), but at
the end of the day
> > we need some relief from the browser vendors
before this is going
> > to get demonstrably better.
> >
> > Regards
> >
> > On Thursday 21 December 2006 12:46 pm, Mark Smith
wrote:
> >>> when there are multiple clients, it breaks
> >>> down... Can anyone shed any light on
this???
> >>
> >> If you're trying to do it with the same
browser in different tabs
> >> then you won't be able to.  Browsers tend to
only allow N
> >> outstanding connections to the server - less
than you need to run
> >> "multiple clients".  Open up Firefox
and also open up IE and start
> >> a client in each - then it should work.
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to
the Google
> Groups "cometd-users" group. To post to this
group, send email to
> cometd-usersgooglegroups.com To unsubscribe from this
group, send
> email to cometd-users-unsubscribegooglegroups.com For more
options,
> visit this group at http://gr
oups.google.com/group/cometd-users
>
> Visit the cometd website at http://www.cometd.com/
> -~----------~----~----~----~------~----~------~--~---

-- 
Alex Russell
alexsitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158
FFDF 2894 6876
alexdojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78
E242 59C3 9723