protocol progress, problems

Hey everyone,

Greg and I had a chance to catch up last week at the
AjaxWorld 
conference, and I think we've agreed that the protocol
doesn't need to 
ACK.

Beyond that, though, there are a couple of things that still
need 
sorting out. Namely:

	- "client blat" or "client pre-auth"
scenarios in which a client 
library may be occasionally connected but will only have an
interest in 
posting events to pre-defined topics. In this scenario
(common when 
retro-fitting old environments with Comet), an application
will need to 
send the /meta/publish event on its first connection with
the server, 
bypassing the normal handshake process. What, if anything,
do we need 
to do to the protocol to support this?
	- what, if any, ordering primitives should we provide? In
our 
discussion, Greg and I agreed that anything that could
gaurantee 
delivery order will need to maintain quite a bit of state on
the 
server, so the question for Bayeux is: do we want to force
every server 
to bite that off?
	- reconnect semantics for server-forced reauth. Greg
brought up a 
scenario in which the server might be clustering but not
sharing state 
(think round-robin), in this scenario the server will need
to return 
a "whatchoo talkin 'bout willis?" response that
forces the client to 
send auth credentials with the next /meta/reconnect request.
This needs 
to be worked out in better detail.
	- /meta/status is entirely undefined right now. I'd like
for us to be 
able to provide the ability to find out, at a minimum, what
topics 
exist and whether or not the connecting client's user is
already 
subscribed to it. Also, a list of authenticating users's
connections 
would be useful. Others? What should these messages look
like?
	- decisions on globbing:
		* should we?
		* if we do, mandatory or negotiated?
		* if negotiated, what should the various styles be named?
		* when subscribing, how does a client indicate the
globbing style to 
be used if multiple styles are supported?

Regards

-- 
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

All, 

inline...

Alex Russell wrote:
> Hey everyone,
> 
> Greg and I had a chance to catch up last week at the
AjaxWorld 
> conference, and I think we've agreed that the protocol
doesn't need to 
> ACK.
> 
> Beyond that, though, there are a couple of things that
still need 
> sorting out. Namely:
> 
> 	- "client blat" or "client
pre-auth" scenarios in which a client 
> library may be occasionally connected but will only
have an interest in 
> posting events to pre-defined topics. In this scenario
(common when 
> retro-fitting old environments with Comet), an
application will need to 
> send the /meta/publish event on its first connection
with the server, 
> bypassing the normal handshake process. What, if
anything, do we need 
> to do to the protocol to support this?

If we accept this, then it has to be optional.
Ie once we know our clients can handshake, we will not
accept a 
blat.

> 	- what, if any, ordering primitives should we provide?
In our 
> discussion, Greg and I agreed that anything that could
gaurantee 
> delivery order will need to maintain quite a bit of
state on the 
> server, so the question for Bayeux is: do we want to
force every server 
> to bite that off?

No.

 	- reconnect semantics for server-forced reauth. Greg
brought up a 
> scenario in which the server might be clustering but
not sharing state 
> (think round-robin), in this scenario the server will
need to return 
> a "whatchoo talkin 'bout willis?" response
that forces the client to 
> send auth credentials with the next /meta/reconnect
request. This needs 
> to be worked out in better detail.

Basically need to define what the client does if a reconnect
fails.

I would like to see a failed reconnect handled with:

   New handshake
   New connect
   resend all the subscribes the client knows about.

But need a backoff strategy - so we don't busy loop on a
failed
server.


> 	- /meta/status is entirely undefined right now. I'd
like for us to be 
> able to provide the ability to find out, at a minimum,
what topics 
> exist and whether or not the connecting client's user
is already 
> subscribed to it. Also, a list of authenticating
users's connections 
> would be useful. Others? What should these messages
look like?
> 	- decisions on globbing:
> 		* should we?
> 		* if we do, mandatory or negotiated?
> 		* if negotiated, what should the various styles be
named?
> 		* when subscribing, how does a client indicate the
globbing style to 
> be used if multiple styles are supported?

I don't think /meta/status needs to be negotiated - it is
either there or not.

I am still cool on globbing. To me it is just like ordering
and acks.
It can be done at a higher level if needed.


I would like to also raise the problem of multiple
windows/tabs and 
the 2 connection limit.     The server can detect this with
cookies
and should do something to make this work better.  Either it
can
warn the client to use only 1 window - or it could make the
second
connection fall back to normal polling?

In jetty at the moment, I have a hack that connections >1
from the 
same browser can have a short poll timeout set.

cheers























 


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

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

inlined

On 10/15/06, Greg Wilkins <gregw.webtidegmail.com> wrote:
>
> All,
>
> inline...
>
> Alex Russell wrote:
> > Hey everyone,
> >
> > Greg and I had a chance to catch up last week at
the AjaxWorld
> > conference, and I think we've agreed that the
protocol doesn't need to
> > ACK.
> >
> > Beyond that, though, there are a couple of things
that still need
> > sorting out. Namely:
> >
> >       - "client blat" or "client
pre-auth" scenarios in which a client
> > library may be occasionally connected but will
only have an interest in
> > posting events to pre-defined topics. In this
scenario (common when
> > retro-fitting old environments with Comet), an
application will need to
> > send the /meta/publish event on its first
connection with the server,
> > bypassing the normal handshake process. What, if
anything, do we need
> > to do to the protocol to support this?
>
> If we accept this, then it has to be optional.
> Ie once we know our clients can handshake, we will not
accept a
> blat.
>
> >       - what, if any, ordering primitives should
we provide? In our
> > discussion, Greg and I agreed that anything that
could gaurantee
> > delivery order will need to maintain quite a bit
of state on the
> > server, so the question for Bayeux is: do we want
to force every server
> > to bite that off?
>
> No.
>
>         - reconnect semantics for server-forced reauth.
Greg brought up a
> > scenario in which the server might be clustering
but not sharing state
> > (think round-robin), in this scenario the server
will need to return
> > a "whatchoo talkin 'bout willis?"
response that forces the client to
> > send auth credentials with the next
/meta/reconnect request. This needs
> > to be worked out in better detail.
>
> Basically need to define what the client does if a
reconnect fails.
>
> I would like to see a failed reconnect handled with:
>
>    New handshake
>    New connect
>    resend all the subscribes the client knows about.
>
> But need a backoff strategy - so we don't busy loop on
a failed
> server.
>
>
> >       - /meta/status is entirely undefined right
now. I'd like for us to be
> > able to provide the ability to find out, at a
minimum, what topics
> > exist and whether or not the connecting client's
user is already
> > subscribed to it. Also, a list of authenticating
users's connections
> > would be useful. Others? What should these
messages look like?
> >       - decisions on globbing:
> >               * should we?
> >               * if we do, mandatory or negotiated?
> >               * if negotiated, what should the
various styles be named?
> >               * when subscribing, how does a
client indicate the globbing style to
> > be used if multiple styles are supported?
>
> I don't think /meta/status needs to be negotiated - it
is either there or not.

While I agree with everything so far.  I think we could have
a
capabilities hash in the handshake that can expose feature
like this.

>
> I am still cool on globbing. To me it is just like
ordering and acks.
> It can be done at a higher level if needed.
>
>
> I would like to also raise the problem of multiple
windows/tabs and
> the 2 connection limit.     The server can detect this
with cookies
> and should do something to make this work better. 
Either it can
> warn the client to use only 1 window - or it could make
the second
> connection fall back to normal polling?
>

I believe the 2 connection limit can be broken with wildcard
subdomains.

I'd like subscriptions to be tied to connection id instead. 
What if I
had multiple comet apps on the same domain?  It'd be hard to
use them
at once.  Let's talk about this more.

Cheers!
David

> In jetty at the moment, I have a hack that connections
>1 from the
> same browser can have a short poll timeout set.
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>

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

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

David Davis wrote:

> I believe the 2 connection limit can be broken with
wildcard subdomains.

It can be broken, but should it be?    Connections do cost
at least
in terms of kernel data structures and buffers
They are not an unlimited resource and there are good reason
that the 
browser have reduced the original 8 connection limit to 2.

So while wildcard domains may be an OK short term solution,
it
will not produce scalable solutions in the long run.

> I'd like subscriptions to be tied to connection id
instead.  What if I
> had multiple comet apps on the same domain?  It'd be
hard to use them
> at once.  Let's talk about this more.

This is exactly the use case for cometd.  We want to
encourage sharing
of the common messaging bus.

OK, this will be difficult to do cross tab/window, but at
least 
have a server side recommendation for detection will help.

cheers


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

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