Web Socket API

The Web Socket protocol enables web applications to maintain bidirectional communications with server-side processes. The typhoonae.websocket package provides a Web Socket Service API for GAE applications. It was introduced by the TyphoonAE 0.1.2 release anddoes not run on the productive Google App Engine platform.

However, in order to enable the Web Socket API for the Google App Engine SDK, go through the following guide.

Patching the Google App Engine SDK (Python) to enable TyphoonAE's Web Socket API

To get an idea how Web Sockets could work with GAE download the SDK 1.5.0 patch from this location. It also includes a demo app and some basic instructions.

Web Borwsers Supporting Web Sockets

• Chrome
• Safari
• Prototype IE8 IE9 implementation
• Mozilla Firefox 4 Note: Since Beta 8 Firefox has disabled Web Sockets by default

Overview

Since Bret Taylor came up with a neat implementation of a Web Socket handler for the Tornado web server, it's no longer a hassle to get an experimental Web Socket service up and running. A client can establish a Web Socket connection to the service which solely utilizes web hooks to dispatch messages to and from an application.

A client requests (1) a web page containing the Java Script call to establish a Web Socket connection (2) to a URL provided by the application. The application and Web Socket service communicate over web hooks (3, 4).

Sending and Receiving Web Socket Messages

We distinguish between two types of incoming Web Socket messages. A handshake message is received once per Web Socket session when the client establishes the connection. This type of message can be handled seperately by a request handler. All other incoming messages can be handled by another request handler. The API we use in our handshake handler as well as in the handler for all other incoming Web Socket messages doesn't differ. However, in many cases it is very useful to handle Web Socket handshake messages seperately from normalmessages.

In order to handle incoming Web Socket requests, add this script handler to the handlers section of the app.yaml file.

  - url: /_ah/websocket/.*
    script: script.py
    login: admin

Define the correct URL mapping for your WSGI application:

  app = google.appengine.ext.webapp.WSGIApplication([
    ('/_ah/websocket/handshake/(.*)', HandshakeHandler),
    ('/_ah/websocket/message/(.*)', MessageHandler),
  ], debug=True)

Our Web Socket API provides a convenience function to obtain the appropriate service URL. It has one argument for additional URI information:

  websocket_url = typhoonae.websocket.create_websocket_url('/foo/bar')

The following request handler receives and sends messages from and to a Web Socket. The POST method is used to receive an incoming message where the first non-self argument contains the additional URI information from above:

  class MessageHandler(google.appengine.ext.webapp.RequestHandler):
    """Handles Web Socket requests."""

    def post(self, path):
      message = typhoonae.websocket.Message(self.request.POST)
      typhoonae.websocket.send_message(
        [message.socket], 'Received: "%s"' % message.body)

A message object has the two attributes socket and body. The former is a string containing the socket id. The latter contains our message body as a unicode string.

The client, usually a Web Socket capable browser, establishes a Web Socket by using Java Script:

  ws = new WebSocket("ws://example.com");

Broadcast Messages

TyphoonAE adds another very useful function which enables an app to broadcast messages to all currently open Web Sockets of an app. Without this convenient method a developer has to implement a solution to remember all open Web Sockets. By using broadcast_message the Web Socket service takes care of it.

  class MessageHandler(google.appengine.ext.webapp.RequestHandler):
    """Handles Web Socket requests."""

    def post(self, path):
      message = typhoonae.websocket.Message(self.request.POST)
      typhoonae.websocket.broadcast_message(message.body)

Handling Closed Sockets

Applications sometimes should be informed when a socket is closed. Therefore, an app can implement a third request handler for the following URL pattern:

    '/_ah/websocket/closed/(.*)'

The success path can be utilized for keeping track of additional informations such as encoded user IDs.

  class SocketClosedHandler(google.appengine.ext.webapp.RequestHandler):
    """Handler for socket closed events."""

    def post(self, path):
      user = decode_user_from_path(path)
      typhoonae.websocket.broadcast_message('%s has left the building' % user)

See http://dev.w3.org/html5/websockets/ for further information on Web Sockets.

출처 : code.google.com

ClamAV 0.98 includes many new features, across many different components
of ClamAV. There are new scanning options, extensions to the libclamav API,
support for additional filetypes, and internal upgrades.

- Signature improvements: New signature targets have been added for
PDF files, Flash files and Java class files. (NOTE: Java archive files
(JAR) are not part of the Java target.) Hash signatures can now specify
a '*' (wildcard) size if the size is unknown. Using wildcard size
requires setting the minimum engine FLEVEL to avoid backwards
compatibility issues. For more details read the ClamAV Signatures
guide.

- Scanning enhancements: New filetypes can be unpacked and scanned,
including ISO9660, Flash, and self-extracting 7z files. PDF
handling is now more robust and better handles encrypted PDF files. 

- Authenticode: ClamAV is now aware of the certificate chains when
scanning signed PE files. When the database contains signatures for
trusted root certificate authorities, the engine can whitelist
PE files with a valid signature. The same database file can also
include known compromised certificates to be rejected! This
feature can also be disabled in clamd.conf (DisableCertCheck) or
the command-line (nocerts). 

- New options: Several new options for clamscan and clamd have been
added. For example, ClamAV can be set to print infected files and
error files, and suppress printing OK results. This can be helpful
when scanning large numbers of files. This new option is "-o" for
clamscan and "LogClean" for clamd. Check clamd.conf or the clamscan
help message for specific details. 

- New callbacks added to the API: The libclamav API has additional hooks
for developers to use when wrapping ClamAV scanning. These function
types are prefixed with "clcb_" and allow developers to add logic at
certain steps of the scanning process without directly modifying the
library. For more details refer to the clamav.h file. 

- More configurable limits: Several hardcoded values are now configurable
parameters, providing more options for tuning the engine to match your
needs. Check clamd.conf or the clamscan help message for specific
details. 

- Performance improvements: This release furthers the use of memory maps
during scanning and unpacking, continuing the conversion started in
prior releases. Complex math functions have been switched from
libtommath to tomsfastmath functions. The A/C matcher code has also
been optimized to provide a speed boost. 

- Support for on-access scanning using Clamuko/Dazuko has been replaced
with fanotify. Accordingly, clamd.conf settings related to on-access
scanning have had Clamuko removed from the name. Clamuko-specific
configuration items have been marked deprecated and should no longer
be used.

There are also fixes for other minor issues and code quality changes. Please
see the ChangeLog file for details.

--
The ClamAV team (http://www.clamav.net/team)