레이블이 comet인 게시물을 표시합니다. 모든 게시물 표시
레이블이 comet인 게시물을 표시합니다. 모든 게시물 표시

2013년 5월 1일 수요일

Comet - Comet with ASP.NET 강좌

이전 블로그에서 이전 함 (원본 글 2013/05/01 작성)

[Comet 강좌 with ASP.NET] 
작성자 : 박경훈   작성일 : 2010-08-16
E-mail : hoonsbara골뱅hanmail.net  Homepage : http://http://www.twitter.com/_HOONS
연재순서
1회 | 2010. 06 | 코멧의 소개와 활용전략
2회 | 2010. 07 | 닷넷을 활용한 코멧 구현 전략
3회 | 2010. 08 | 코멧을 이용한 웹 채팅 만들기
[코멧] 1. 코멧의 소개 http://www.hoons.net/lecture/view/521
기술장점단점
iframe구현이 쉽다 로딩이 표시된다.IE에서 딸깍딸깍 소리가 난다.
크로스 도메인을 지원하지 않는다.
htmlFile크로스 도메인을 어느 정도 사용할 수 있다.
로딩바 표시나 딸깍 로딩소리를 없앨 수 있다.
Chunked인코딩을 이용해서 스트리밍 서비스를 제공할 수 있다. 		IE에서만 동작된다.
JSONP 크로스 도메인 문제를 해결할 수 있다.
로딩바 표시나 별도의 소리가 나지 않는다.		Chunked 인코딩을 이용할 수 없다.
XMLHttpRequestXmlHttpRequest 최신 브라우저에서는 스트리밍 서비스를 구현할 수 있다. 크로스 도메인을 지원하지 않는다.
[표1] 롱폴링을 위한 기술들

커넥션 관리 이슈

롱폴링의 경우 서버에서 커넥션을 물고 있기 때문에 커넥션 관리 이슈를 빼놓고 생각해 볼 수 없다. 기존의 폴링은 커넥션을 자주 연결하고 끊기 때문에 서버 트래픽이나 서버 CPU의 영향을 주게 된다면 커넥션을 물고 있을 경우 가장먼저 생각해 봐야 하는 것이 메모리 이슈이다. 그리고 두 번째는 브라우저에서 한 사이트당 최대 커넥션 수를 제한하고 있기 때문에 잘못 했다가는 사이트가 먹통이 되어 버리는 브라우저의 이슈가 있다. 

그렇다면 먼저 메모리 이슈부터 살펴보도록 하겠다. 물론 커넥션당 하나의 스레드가 할당될 것이고 어떤 작업을 하게 되느냐에 따라서 CPU 비용을 사용하게 될 수도 있지만 적절히 스레드를 쉬어가면서 운영을 하게 되면 일반적으로 CPU 때문에 크게 이슈가 되지는 않을 것이다. 그것보다도 서버를 운영하다 보면 부딪치게 되는 이슈가 바로 메모리 이슈이다. 보통 스레드와 스택기반의 커넥션을 이루게 될 경우 한 사용자 당 약 2메가 정도를 예상해 봐야 할 것이다. 

이 수치는 약 오천 명이 동시 접속을 이루게 될 경우 10기가 정도의 메모리가 소모된다는 것이다. 하지만 웹에 오천 명이 동시에 접속한다는 것 자체가 굉장히 대단한 수치이다. 대한민국 국민의 0.01%가 모두 한 사이트에 들어와서 특정 서비스를 이용하고 있다는 것이기 때문이다. 때문에 대규모의 서비스가 아닐 경우라면 크게 걱정하지 않아도 될 것이다. 물론, 국내에서 몇 손가락 안에 드는 그런 어마어마한 사이트에서 웹 채팅을 구현한다고 한다면 각각 서버를 분할해서 구현해야 할 것이다. 하지만 이 내용은 이번 기사의 범위에서 벗어나므로 다루지 않도록 하겠다. 

두 번째로 생각해 볼 이슈는 바로 브라우저의 커넥션 제한 이슈이다. 브라우저는 각각의 최대 커넥션 개수를 가지고 있다. 즉, 최대 커넥션 개수 범위 안에서 커넥션을 공유하면서 서버와 통신을 하게 되는 것이다. 하지만 롱폴링을 이용하게 되면 하나의 커넥션을 헌납해야 한다. 다음 [표1]은 각 브라우저 별로 커넥션 수를 보여주고 있다. 


[표1] 브라우저별 커넥션 수

원래 HTTP 프로토콜에서 권고하는 도시 커넥션 수는 2개였고, 지금도 그러하다. 하지만 파이어폭스3가 발표될 때 6개로 확장을 시작하였고, 크롬도 그에 맞서 6개로 확장하여 지원하고 있다. 그에 맞서 IE8도 6개로 확장하였다. 왜냐하면 이 커넥션 숫자가 바로 웹 사이트를 다운로드 하는 속도와 아주 밀접하게 연결이 되어있기 때문이다. 하지만 조금 오래된 브라우저들은 여전히 2개의 커넥션만 허용하고 있기 때문에 웹사이트가 먹통이 되거나 굉장히 느려질 수 있기 때문에 커넥션 관리를 철저하게 해주어야 한다. 


[코멧] 3. 코멧을 이용한 웹 채팅 만들기 http://www.hoons.net/Lecture/View/523


세번째 강좌에서는 특이하게도 chunked transfer 형식을 빌려서 만들었음.
Comet wikipedia 같은 곳에서 보면 multipart response를 사용하는 것이 일반적인 것 같던데..
하지만 두 방법 모두 http transfer를 위해 socket connection 연결한 상태에서 respone를 나눠서 계속 보내는 것이라 socket connection 유지 및 관리에서 문제가 되지 않을까?

* [참고] HTTP Chunked Transfer
 - http://tools.ietf.org/html/rfc2616 ( 3.6.1 Chunked Transfer Coding )
   : 일반적인 HTTP transfer는 한번의 request에 대해서 한번의 response로 끝나게 된다. ( 1xx continue 경우 제외), 하지만 특정 소스(live stream 같이 전체 size를 판단하지 못하고 client의 capability상 전체 size를 한번에 보내지 못할 경우, 아님 편의상)를 임의 사이즈(chunk)로 나눠서 전달할 수 있다. (HTTP 1.1 에만 국한)
 * [참고] HTTP Multipart response :      - http://www.ietf.org/rfc/rfc1521.txt (Section 7.2)
     -  http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html
시간: 댓글 없음:
라벨: ,

Comet, WebSocket solution - Atmosphere

이전 블로그에서 이전 함 (원본 글 2013/05/01 작성)

Atmosphere


The Asynchronous WebSocket/Comet Framework

 The Atmosphere Framework contains client and server side components for building Asynchronous Web Application. The majority of popular frameworks are either supporting Atmosphere or supported natively by the framework. The Atmosphere Framework supports all majors Browsers and Servers

Atmosphere transparently supports WebSockets, Server Side Events (SSE), Long-Polling, HTTP Streaming (Forever frame) and JSONP.

Atmosphere is a Java technolog framework that provides a common API for using the Comet and WebSocket features of many of the web servers, including Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb, JBoss, and Resin. 

Atmosphere can detect native server APIs (for Comet and WebSockets) and switch back to Servlet 3.0, if available, for Comet. Or, also for Comet, it will fall back to a "managed" asynchronous mode (but not as scalable as Jetty Continuations). Atmosphere has been around for more than two years, and it is still in active development.


The Atmosphere framework is composed of the Atmosphere runtime, which provides a common API for all different web server solutions and standards. On top of this, the client can access the API and Reverse Ajax features through the Google Web Toolkit (GWT) by setting up a mere servlet. Or, you can also use Jersey, a framework implementing the JSR-311 (JAX-RS specification). 

Atmosphere's strength remains on the server side: it provides a standardized API that covers all of the different solutions and ways to communicate with WebSockets or Comet. Atmosphere does not use a protocol between the client and server, like Socket.IO and CometD. Both libraries provide a client-side JavaScript and a server-side servlet that communicate using a specific protocol (for handshaking, messaging, acknowledgment, and heartbeat). Atmosphere's goal is to provide a common communication channel on the server side.

Atmosphere comes with a jQuery client library to facilitate the connection setup, which is able to automatically detect the best transport available (WebSockets or CometD). Usage of Atmosphere's jQuery plugin is similar to the HTML5 WebSockets API. First, you connect to the server, register a callback to receive messages, and then you can push some data.

ProsCons
If you have to deploy a web application in several web servers that you can't control. You'll have a better chance that the Reverse Ajax features of your application work correctly due to the number of web servers supported by Atmosphere.
When you need a common API over a raw Reverse Ajax communication, without any protocol defined, because you want to develop or extend it.
Lack of documentation about Atmosphere's architecture, project, concepts, and APIs, which is helpful if you need to go into the source code or analyze several provided samples. The API is highly technical, and sometimes obscure, compared to the simple APIs of other frameworks, such as Socket.IO and CometD. Even when using Atmosphere annotations, some names and attributes were too technical.
Though a good abstraction on the server side, there is not a good client library. There is no protocol, so all additional features are left to the developer. The current library is too simple for the needs of a big, scalable web application if you require advanced timeout detection, acknowledgement, back-off, cross-domain and so on, especially when working with mobile devices. In this case, CometD is much more reliable; it leverages a communication protocol that can be used to activate some control flow and error detection, all provided within CometD. Using the CometD JavaScript client with the Atmosphere CometD plugin could be a good alternative if you need extra features.


시간: 댓글 없음:
라벨: , ,

Comet, WebSocket solution - CometD

이전 블로그에서 이전 함 (원본 글 2013/05/01 작성)

 Welcome to CometD Project @ The Dojo Foundation 
 

☄ CometD Bayeux Ajax Push

CometD is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet. The term 'Comet' was coined by Alex Russell in his post Comet: Low Latency Data for the Browser.
CometD is a Dojo Foundation project to provide implementations of the Bayeux protocol in javascript, java, perl, python and other languages. Other organizations (eg. Sun, IBM and BEA) also have implementations of Bayeux that are not strictly part of the CometD project, but where possible they are linked to from this site.

CometD makes use of an Ajax push technology pattern known as Comet, but also uses emerging web standards such as WebSocket for low latency communication.

The CometD project provides Java and JavaScript libraries that allow you to write low-latency, server-side, event-driven web applications in a simple and portable way. You can therefore concentrate on the business side of your application rather than worrying about low-level details such as the transport (HTTP or WebSocket), the scalability and the robustness. The CometD libraries provide these latter characteristics.


he CometD project provides the Bayeux specification, that defines the protocol used to exchange information between client and server, and provides (eventually) standardized APIs for servers and clients.
Currently the API bindings for JavaScript (on the client) and Java (for both client and server) have reached a stable status.



The CometD framework, an event-driven communication solution based on HTTP, has been around for several years. Version 2 added support for annotation configuration and WebSockets. The CometD framework provides a Java server part and a Java client part, plus JavaScript client libraries based upon jQuery and Dojo. CometD uses a standardized communication protocol called Bayeux, allowing you to activate some extensions for message acknowledgement, flow control, synchronization, clustering, and so on.
CometD's event-driven approach fits very well with the new concept of event-driven web development. As with traditional desktop user interfaces, all of the components communicate through a bus to send notifications and receive events. All communication is therefore asynchronous.
The CometD framework:
  • Is well-documented.
  • Provides samples and Maven archetypes to facilitate the startup of a project.
  • Has a well-designed API that enables extension development.
  • Provides a clustering module, called Oort, that gives you the ability to run multiple CometD web servers as nodes in a cluster behind a load balancer to scale to a larger number of HTTP connections.
  • Supports security policies to allow a fine-grain configuration of who can send messages over which channel.
  • Integrates quite well with Spring and Google Guice (dependency injection frameworks).

CometD is bundled with three transports: JSON, JSONP, and WebSocket. They depend upon Jetty Continuations and the Jetty WebSocket API. By default, CometD can be used in Jetty 6, 7, and 8, as well as any other servers supporting the Servlet 3.0 Specification. 


ProsCons
CometD offers a complete solution, from client and server side, and also from a standalone Java client to a server. The framework is well-documented, has a good API, and is easy to use. Best of all, it has an event-driven approach. CometD and Bayeux are part of many event-driven web applications. Other Reverse Ajax frameworks don't provide any event-driven mechanisms, forcing end users to develop their own custom solution.
CometD supports many required features, such as reconnection, reliable timeout detection, back-off, batching, message acknowledgement, and more that you won't find in other Reverse Ajax frameworks. CometD lets you achieve the most reliable, low-latency communication possible.
CometD currently does not support any Servlet 2.5 containers other than Jetty for Comet (Tomcat), and it does not support Glassfish/Grizzly WebSocket.


[CometD 2 Concepts]

- High level View

 : CometD implements a web messaging system, in particular a web messaging system based on the publish/subscribe paradigm.

For example, let's imagine that clientAB is subscribed to channels /A and /B, and clientB is subscribed to channel /B.
If a publisher publishes a message on channel /A, only clientAB will receive it. On the other hand, if a publisher publishes a message on channel /B, both clientAB and clientB will receive the message. Furthermore, if a publisher publishes a message on channel /C, neither clientAB nor clientB will receive the message, that will just end its journey on the server.
Re-routing broadcast messages is the default behavior of the server, and it does not need any application code to perform the re-routing.

* 좀 burden 인것 같이 보이지만 central server를 두고 각 client들이 server로 subscribe하여 event/message를 받는 구조. 자신이 보낸 메세지가 각 channel(subscribe한)을 통해 모든 client(자신 포함)들에게 전달되는 구조.


- Low Level View

 CometD, at its heart, is a client/server system that communicates via a protocol, the Bayeux protocol.

In the CometD implementation, the client/server communication is captured by the half-object plus protocol pattern: when a half-object on the client establishes a communication conduit with the server, its correspondent half-object is created on the server, and the two may - logically - communicate.

The transport can be based on the HTTP protocol, but in recent CometD versions also on the WebSocket protocol (and more transports can be plugged in).

즉 CometD에서는 messaging 전달을 위해서 server, client단에 half object를 만들어서 서로간에 http, websocket을 사용해서 전달하도록 되어 있다는 얘기 인듯... 이렇게 되면  HOPP의 장점을 받을 수 있을 듯.

 * [참고] half-object plus protocol pattern (HOPP)

 - Divide an object which needs to be accessed from more than one address space into two interdependent half-objects (one in each address space) with a protocol between them. 
 - distribute systems상에서 여러 address spaces(아마도 다른 system들이 되지 않을까? 아님 하나의 system에서 각기 다른 application/component상에서 값들을 받아야 할 경우가 아닐까?)에서 실행이 되어야 할 경우 해당 처리를 위한 객체를 분리(half-object)하여 각 address spaces에서 동작하게 하고 서로간에 data/state 전달을 protocol을 사용하는 구조 인것 같음.
 - 장점으로는 처리해야할 행위를 각기 다른 분산 시스템에서 처리하게 되어 performance나 scalability 측면에서는 장점이겠으나 각 half-object 간 data synchronization 측면에서 optimization이 필요할 것으로 보임.
* 자세한 것은 책 보세요.




[Bayeux Specification]

- specification :  http://cometd.org/documentation/bayeux/spec (나중에 좀 읽어 봐야 겠다.)

Submitted by gregwilkins on Thu, 06/05/2008 - 01:59. 
The primary purpose of Bayeux is to support responsive bidirectional interactionsbetween web clients using Ajax and the web server.

Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client.

The messages are routed via named channels and can be delivered:
server to client
client to server
client to client (via the server)
By default, publish/subscribe routing semantics are applied to the channels.

Delivery of asynchronous messages from the server to a web client is often described as"server-push".
The combination of server push techniques with an Ajax web application has been called "Comet".
CometD is a project by the Dojo Foundation to provide multiple implementation of the Bayeux protocol in several programming languages.

The Bayeux protocol seeks to reduce the complexity of developing Comet applications by allowing implementors to more easily interoperate, to solve common message distribution and routing problems, and to provide mechanisms for incremental improvements and extensions.


시간: 댓글 1개:
라벨: , ,

Comet, WebSocket - Reverse Ajax (IBM article)

이전 블로그에서 이전 함 (원본 글 2013/05/01 작성)

[Reverse Ajax, Mathieu Carbou, Java Web Architect, Ovea]
Part 1: Introduction to Comet
Part 2: WebSockets
Part 3: Web servers and Socket.IO
Part 4: Atmosphere and CometD
* IBM article이 그렇듯이 충실하다.. 이것만 제대로 보면 OK.


Listing 2. JavaScript polling
setInterval(function() { 
    $.getJSON('events', function(events) { 
        console.log(events); 
    }); 
}, 2000);


The second technique, which is more reliable, is to use the multi-part flag supported by some browsers (such as Firefox) on theXMLHttpRequest object. An Ajax request is sent and kept open on the server side. Each time an event comes, a multi-part response is written through the same connection. Listing 6 shows an example.

Listing 6. Sample JavaScript code to set up a multi-part streaming request
var xhr = $.ajaxSettings.xhr(); 
xhr.multipart = true; 
xhr.open('GET', 'ajax', true); 
xhr.onreadystatechange = function() { 
    if (xhr.readyState == 4) { 
        processEvents($.parseJSON(xhr.responseText)); 
    } 
}; 
xhr.send(null);

On the server side, things are a little more complicated. You must first set up the multi-part request, and then suspend the connection. Listing 7 shows how to suspend an HTTP streaming request. (Part 3 of this series will cover the APIs in more detail.)

Listing 7. Suspending an HTTP streaming request in a servlet using Servlet 3 API
protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
        throws ServletException, IOException { 
    // start the suspension of the request
    AsyncContext asyncContext = req.startAsync(); 
    asyncContext.setTimeout(0); 

    // send the multipart separator back to the client
    resp.setContentType("multipart/x-mixed-replace;boundary=\""
        + boundary + "\""); 
    resp.setHeader("Connection", "keep-alive"); 
    resp.getOutputStream().print("--" + boundary); 
    resp.flushBuffer(); 

    // put the async context in a list for future usage
    asyncContexts.offer(asyncContext); 
}

Now, each time an event occurs you can iterate over all suspended connections and write the data to them, as shown in Listing 8:

Listing 8. Send events to a suspended multi-part request using Servlet 3 API
for (AsyncContext asyncContext : asyncContexts) { 
    HttpServletResponse peer = (HttpServletResponse) 
        asyncContext.getResponse(); 
    peer.getOutputStream().println("Content-Type: application/json"); 
    peer.getOutputStream().println(); 
    peer.getOutputStream().println(new JSONArray()
        .put("At " + new Date()).toString()); 
    peer.getOutputStream().println("--" + boundary); 
    peer.flushBuffer(); 
}


As usual, there are advantages and disadvantages.
  • Advantage: Only one persistent connection is opened. This is the Comet technique that saves the most bandwidth usage.
  • Disadvantage: The multi-part flag is not supported by all browsers. Some widely used libraries, such as CometD in Java, reported issues in buffering. For example, chunks of data (multi-parts) may be buffered and sent only when the connection is completed or the buffer is full, which can create higher latency than expected.



The second, and recommended, method to implement Comet is to open an Ajax request to the server and wait for the response. The server requires specific features on the server side to allow the request to be suspended. As soon as an event occurs, the server sends back the response in the suspended request and closes it, exactly like you close the output stream of a servlet response. The client then consumes the response and opens a new long-lived Ajax request to the server, as shown in Listing 9:

Listing 9. Sample JavaScript code to set up long polling requests
function long_polling() { 
    $.getJSON('ajax', function(events) { 
        processEvents(events); 
        long_polling(); 
    }); 
} 

long_polling();

On the back end, the code also uses the Servlet 3 API to suspend the request, as in HTTP streaming, but you don't need all the multi-part handling code. Listing 10 shows an example.

Listing 10. Suspending a long polling Ajax request
protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
        throws ServletException, IOException { 
    AsyncContext asyncContext = req.startAsync(); 
    asyncContext.setTimeout(0); 
    asyncContexts.offer(asyncContext); 
}

When an event is received, simply take all of the suspended requests and complete them, as shown in Listing 11:

Listing 11. Completing a long polling Ajax request when an event occurs
while (!asyncContexts.isEmpty()) { 
    AsyncContext asyncContext = asyncContexts.poll(); 
    HttpServletResponse peer = (HttpServletResponse) 
        asyncContext.getResponse(); 
    peer.getWriter().write(
        new JSONArray().put("At " + new Date()).toString()); 
    peer.setStatus(HttpServletResponse.SC_OK); 
    peer.setContentType("application/json"); 
    asyncContext.complete(); 
}

In the accompanying downloadable source files, the comet-long-polling folder contains a long polling sample web application that you can run using the mvn jetty:run command.
  • Advantages: It's easy to implement on the client side with a good error-handling system and timeout management. This reliable technique also allows a round-trip between connections on the server side, since connections are not persistent (a good thing, when you have a lot of clients on your application). It also works on all browsers; you only make use of theXMLHttpRequest object by issuing a simple Ajax request.
  • Disadvantage: There is no main disadvantage compared to other techniques. But, like all techniques we've discussed, this one still relies on a stateless HTTP connection, which requires special features on the server side to be able to temporarily suspend it



Listing 2. JavaScript client code
var ws = new WebSocket('ws://127.0.0.1:8080/async'); 
ws.onopen = function() { 
    // called when connection is opened 
}; 
ws.onerror = function(e) { 
    // called in case of error, when connection is broken in example 
}; 
ws.onclose = function() { 
    // called when connexion is closed 
}; 
ws.onmessage = function(msg) { 
    // called when the server sends a message to the client. 
    // msg.data contains the message. 
}; 
// Here is how to send some data to the server 
ws.send('some data'); 
// To close the socket:
ws.close();

Request URL:ws://127.0.0.1:8080/async 
Request Method:GET 
Status Code:101 WebSocket Protocol Handshake 

Request Headers 
Connection:Upgrade 
Host:127.0.0.1:8080 
Origin:http://localhost:8080 
Sec-WebSocket-Key1:1 &1~ 33188Yd]r8dp W75q 
Sec-WebSocket-Key2:1   7;    229 *043M 8 
Upgrade:WebSocket 
(Key3):B4:BB:20:37:45:3F:BC:C7 

Response Headers 
Connection:Upgrade 
Sec-WebSocket-Location:ws://127.0.0.1:8080/async 
Sec-WebSocket-Origin:http://localhost:8080 
Upgrade:WebSocket 
(Challenge Response):AC:23:A5:7E:5D:E5:04:6A:B5:F8:CC:E7:AB:6D:1A:39


public final class ReverseAjaxServlet extends WebSocketServlet { 
    @Override 
    protected WebSocket doWebSocketConnect(HttpServletRequest request,
                                           String protocol) { 
        return [...] 
    } 
}

With Jetty, there are several ways to handle a WebSocket handshake. The easier way is to subclass Jetty's WebSocketServletand implement the doWebSocketConnect method. This method asks you to return an instance of the Jetty's WebSocket interface. You have to implement the interface and return a sort of endpoint representing the WebSocket connection. Listing 5 provides a sample.

Listing 5. WebSocket implementation sample
class Endpoint implements WebSocket { 

    Outbound outbound; 

    @Override 
    public void onConnect(Outbound outbound) { 
        this.outbound = outbound;    
    } 

    @Override 
    public void onMessage(byte opcode, String data) { 
        // called when a message is received 
        // you usually use this method 
    } 

    @Override 
    public void onFragment(boolean more, byte opcode, 
                           byte[] data, int offset, int length) { 
        // when a fragment is completed, onMessage is called. 
        // Usually leave this method empty. 
    } 

    @Override 
    public void onMessage(byte opcode, byte[] data, 
                          int offset, int length) { 
        onMessage(opcode, new String(data, offset, length)); 
    } 

    @Override 
    public void onDisconnect() { 
        outbound = null; 
    } 
}

To send a message to the client, you write to the outbound, as shown in Listing 6:

Listing 6. Sending a message to the client
if (outbound != null && outbound.isOpen()) {
    outbound.sendMessage('Hello World !');
}

To disconnect the client and close the WebSocket connection, use outbound.disconnect();.
WebSockets is a very powerful way to implement a bi-directional communication with no latency. It is supported by Firefox, Google Chrome, Opera, and other modern browsers. According to the jWebSocket website:
  • Chrome includes native WebSockets since 4.0.249.
  • Safari 5.x includes native WebSockets.
  • Firefox 3.7a6 and 4.0b1+ includes native WebSockets.
  • Opera includes native WebSockets since 10.7.9067.
For more information about jWebSocket, see Resources.
WebSockets provides powerful, bi-directional, low-latency, and easy-to-handle errors. There isn't a lot of connection, like Comet long polling, and it doesn't have the drawbacks of Comet streaming. The API is also very easy to use directly without any additional layers, compared to Comet, which requires a good library to handle reconnection, timeout, Ajax requests, acknowledgments, and the optionally different transports (Ajax long polling and jsonp polling).

시간: 댓글 없음:
라벨: , , ,

2013년 4월 30일 화요일

Comet, WebSocket

이전 블로그에서 이전 함 (원본 글 2013/04/30 작성)




[WebSocket]

- WebSocket 소개

* 말그대로 web browser, server간에서 socket을 사용하는 방법
 browser<->server간 동작을 위해 asynchronous socket operation을 지원해야 겠지..
뭐 요즘은 native programming에서도 asynchronous socket을 사용해서 프로그래밍하니.. 

- WebSocket 지원 현황
* 현재 Android browse는 web socket을 지원하지 않는다.
* 그외 대다수의 Browser(IE10, FF 20, Chrome 26, Safari, Opera)들에서 지원 중

- WebSocket과 Socket.io( Node.js 모듈)



[Comet, WebSocket 지원 현황]
* 2012년 4월 자료이긴 하지만 참고..


(LP: long-Polling HS: Http Streaming)
ServerVersionNative CometNative WebSocketWebSocketsLPHSJSONP
Netty3.3.xXXXXXX
Jetty5.xXXX
Jetty6.xXXXX
Jetty7.xXXXXXX
Jetty8.xXXXXXX
GlassFish2.xXXXX
GlassFish3.x to 3.1.1XXXX
GlassFish3.1.2XXXXXX
Tomcat5.xXXX
Tomcat6.xXXXX
Tomcat7.0.26 and lowerXXXX
Tomcat7.0.27 and upXXXXXX
JBoss5.xXXX
JBoss6.xXXXX
JBoss7.xXXXX
WebLogic10.xXXXX
WebLogic11.x and upXXXX
Resin2.xXXX
Resin3.xX XXXX
WebSphere7.xXXX
WebSphere8.xXXX

Supported Browsers

The current list of Browsers have been tested with Atmosphere using the atmosphere.js Javascript library and the transport they supports.
BrowserVersionWebSocketsLong-PollingHttp StreamingJSONP
Firefox3.x to 8.xXXX
Firefox9.x to 11.xXXXX
Chrome12.x and lowerXXX
Chrome13.x and higherXXXX
Internet Explorer6x to 9.xXXX
Internet Explorer10.xXXXX
Opera10.x and lowerXX
Opera11.xXXX
Safari4.xXXX
Safari5.xXXXX
Android2.x and upXXX
Safari (iOS)1.x to 4.xXXX
Safari (iOS)5.xXXXX



[Comet, WebSocket solutions]

- 지원 solution list

- CometD

- Atmosphere

시간: 댓글 없음:
라벨: ,
피드 구독하기: 글 (Atom)