Comet-Jetty(1)CometD Design and Go through document
First of all, I tried jetty6.1.3, chat demo. I have demoed that before. But I do not think it is a good way to solve my problem on hand.
So I try to download the latest cometd2.x project and read the document.
1. Prepare the project
>git clone https://github.com/cometd/cometd.git
build the whole project at the root path
>mvn clean install
I think there are many parts useful to me.
1.1 full chat applications with jquery
1.2 examples of extensions such as message acknowledgement, reload, timesync and timestamp.
1.3 an example of how to echo private message to a particular client only
running the demos with maven.
>cd cometd-demo
>mvn jetty:deploy-war
Then I visit the URL http://localhost:8080 to take a look at the demo.
2. Primer
2.2.1 Setting Up the Project in Maven Way
CometD libraries using maven uses the maven archetype, which create the skeleton of the project.
>cd D:\work\cometd
>mvn archetype:generate -DarchetypeCatalog=http://cometd.org
I choose 5 to have a try here:
5: http://cometd.org -> org.cometd.archetypes:cometd-archetype-spring-jquery-jetty7 (2.4.3 - CometD
archetype for creating a server-side event-driven web application)
Confirm properties configuration:
groupId: com.sillycat
artifactId: easycometd
version: 1.0
package: com.sillycat.easycometd
cometdVersion: 2.4.3
jettyVersion: 7.6.4.v20120524
slf4jVersion: 1.6.4
springVersion: 3.1.1.RELEASE
I copy the directory to my working directory d:/work/easy/easycometd.
>cd d:/work/easy/easycometd
>mvn eclipse:eclipse
I can import this project to eclipse. I delete the parent configuration in pom
<parent>
<artifactId>cometd-project</artifactId>
<groupId>org.cometd</groupId>
<version>2.5.0-SNAPSHOT</version>
</parent>
And take a look at the demo.
>mvn install jetty:run
We can visit this URL http://localhost:8080/easycometd/, but there is not much information. I will try more on this demo after I read documents.
3. Concept & Architecture
The CometD Project uses the Bayeux protocol to exchange the information between the client and the server.
The unit of information exchanged is a Bayeux message formatted in JSON.
All messages the client and server exchange have a channel field. The channel field provides the characterization of messages in classes. The channel is a central concept in CometD: publishers publish messages to channels, and subscribers subscribe to channels to receive messages. This is strongly reflected in the CometD APIs.
3.1.1.Channel Definitions
A channel that starts with /meta/ is a meta channel, a channel that starts with /service/ is a service channel, and all other channels are broadcast channels.
3.1.1.1 Meta Channels
CometD implementation creates meta channels, application can not. Provide information about protocol.
3.1.1.2. Service Channels
Applications create service channels for request/response style of communication.
3.1.1.3. Broadcast Channels
Applications also create broadcast channels. One sender wants to broadcast information to multiple recipients.
3.1.1.4. Use of Wildcards in Channels
3.3.1 Sessions
Client Sessions
org.cometd.bayeux.client.ClientSession
org.cometd.bayeux.client.BayeuxClient
Server Sessions
org.cometd.bayeux.server.ServerSession
they are the counterpart of client sessions. When a client creates a client session, it is not initially associated with a correspondent server session. Only when a client session establishes the Bayeux communication with the server does the server create its correspondent server session, as well as the link between the two half-objects.
Local Sessions
org.cometd.bayeux.server.LocalSession
Local sessions can be thought of as clients living in the server. They do not represent a remote client, but instead a server-side client.
3.3.4 Message Processing
3.3.5. Application Interaction
4.1. Configuring and Initializing
in application.js, we can see the configuring:
var cometURL = location.protocol + "//" + location.host + config.contextPath + "/cometd";
cometd.configure({
url: cometURL,
logLevel: 'debug'
});
After we call cometd.handshake(); The client will connect to the server.
The call to handshake() (or to init()) initiates the Bayeux communication with the Bayeux server.
4.2. Handshaking
The client and the server negotiate the type of transport to use.
Once the transport negotiates successfully, the server informs the client with the detailed timings of the requests.
4.3.4. Subscribers and Listeners
addListener() ----> removeListener()
subscribe() ----> unsubscribe()
addListener()
Must be used to listen to meta channel messages
May be used to listen to service channel messages
Should not be used to listen broadcast channel messages(use subscribe() instead)
Is synchronous
Does not involve any communication with the Bayeux server, and as such can be called before calling handshake().
subscribe()
Must not be used to listen to meta channels messages
May be used to listen to service channel message(but recommend, prefer to use addListener())
Should be used to listen to broadcast channel messages
Involves a communication with the Bayeux server and as such cannot be called before calling handshake().
Is asynchronous:
4.3.6. Wildcard Subscriptions
cometd.subscribe("/chatrooms/*", function(message) { ... });
4.3.7. Meta Channel List
/meta/handshake
/meta/connect
/meta/disconnect
/meta/subscribe
/meta/unsubscribe
/meta/publish
/meta/unsuccessful
4.4. Publishing
publish data onto a certain channel
cometd.publish('/mychannel',{ mydata: { foo: 'bar' } }};
It is asynchronous: it returns immediately, well before the Bayeux server has received the message.
4.7. JavaScript Transports
4.7.1. The long-polling Transport
The long-polling transport is the default transport if the browser and the server do not support WebSockets. The data is sent to the server by means of a POST request with Content-Type application/json via a plain XMLHttpRequest call.
This transport is used when the communication with the Bayeux server happens on the same domain.
Client will ask the Server for reply, if no data, Client will wait to timeout, if data, Client will receive and make another request.
4.7.2. The callback-polling Transport
The callback-polling transport is used when the communication with the Bayeux server happens on a different domain.
To overcome XMLHttpRequest restrictions, this transport uses the JSONP script injection, which injects a <script> element whose src attribute points to the Bayeux server.
4.7.3. The websocket Transport
4.7.4. Unregistering Transports
var cometd = dojox.cometd; // Dojo style
var cometd = $.cometd; // jQuery style
cometd.unregisterTransport('websocket');
The purpose is to disable certain transports that might be unreliable.
references:
http://timyang.net/category/architecture/
http://sillycat.iteye.com/blog/563598
http://wiki.eclipse.org/Jetty/
https://github.com/eclipse/jetty.project
http://git.eclipse.org/gitroot/jetty/org.eclipse.jetty.project.git
http://ftp.jaist.ac.jp/pub/eclipse/jetty/index.html
http://oss.sonatype.org/content/groups/jetty/
http://cometd.org/
http://haidii.iteye.com/blog/481004
https://github.com/cometd
https://github.com/cometd/cometd.git
http://docs.cometd.org/reference/
http://abentotoro.blog.sohu.com/203996578.html
http://yaojialing.iteye.com/blog/716094
http://docs.cometd.org/reference/#d0e117