NetScaler Web2.0 Push Technology Overview
Upcoming SlideShare
Loading in...5
×
 

NetScaler Web2.0 Push Technology Overview

on

  • 3,423 views

NetScaler Web 2.0 Push technology scales Comet or Reverse Ajax applications that depend on long running idle client connections. It offloads server load by handling all the client connections on the ...

NetScaler Web 2.0 Push technology scales Comet or Reverse Ajax applications that depend on long running idle client connections. It offloads server load by handling all the client connections on the NetScaler and publishing a REST API for the server application to send periodic updates.

Statistics

Views

Total Views
3,423
Views on SlideShare
3,388
Embed Views
35

Actions

Likes
0
Downloads
69
Comments
0

3 Embeds 35

http://10.102.131.91 21
http://www.slideshare.net 13
http://ageedev.citrix.com:8080 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

NetScaler Web2.0 Push Technology Overview NetScaler Web2.0 Push Technology Overview Presentation Transcript

  • Web 2.0 Push Technical overview
    Netscaler Product Group
  • Web 2.0 - Server Push or Reverse Ajax
    Reverse Ajax is the ability to push data from a web or app server to the browser, without user interaction
    "Publish-Subscribe" model
    Clients subscribe to information channels/feed
    Servers push “new” information out to the subscribers
    Many different names and techniques
    HTTP Server Push
    HTTP Streaming
    COMET (Server Push + Long Polling)
    Long Polling
    BOSH (Bidirectional-streams Over Synchronous HTTP )
    © The Coding Machine
  • Client Update: Three Common Techniques
    Server Push
    Client Pull
  • Server
    Client
    Client
    Req
    Req_1
    t
    Quiet period
    Quiet period (y)
    Query finishes
    Req_2
    Quiet period
    Quiet period (y)
    Query finishes
    Chunk_1 (data)
    Chunk_0 (data)
    Chunk_2 (data)
    Req_3
    Server Push – Two Common Techniques
    Long Polling
    Streaming
    Server
    Time
    Connection resource tied up on Server
    Connection resource tied up on Server
    t + y
    t + 2y
  • NetScaler Web 2.0 Push: Offloading Connection Management
    Benefits
    Improves server utilization by 10x
    Improves application responsiveness
    Cuts data center energy and cooling costs
    Availability
    Available in NetScaler 9.x – (March 2009)
    Available in Platinum and Enterprise edition
    Requires custom script development to adapt a given application to work with our Push technology to enable tagging data streams as “Server Push-able”
    Millions of clients
    Few servers
  • NetScaler Web 2.0 Push: Asynchronous Connection Mgmt
    • NetScaler acts as a full proxy between subscribers (persistent clients) and publishers (push servers)
    • Parks millions of persistent client connections
    • Enables configuration driven approach to identifying a client connection and server push setup – aka label
    • Offloads client connection management from servers
    • Reuses server connections thus improving server utilization and “push”es data to client based on returned label
    • Enables all existing policy, availability and security services across asynchronous interaction
  • NetScaler Web 2.0 Push Message Flow
    Step 1: Connection Setup
    Step 2: Client Identification
    Step 3: Connection Labeling
    Step 4: Server Push
  • NetScaler Web 2.0 Push Building Blocks
    Connection Labeling Protocol
    Receive and terminate connections; decrypt and analyze every request
    Setup transaction label over multiplexed HTTP connections
    Push Switching Protocol
    NetScaler accepts asynchronous out of band label updates over few TCP connections
    NetScaler demultiplexes label and dispatches updates over persistent client connections
  • NetScaler Web 2.0 Push : An Example Setup
    Server Push messages are sent to NetScaler over a few pooled connections
    Client-VIP
    10.217.6.86:80
    Push-VIP
    10.217.6.87:80
    Server
    10.217.6.53:80
    Client
    10.216.134.59
  • PUSH_VIP: IP-Prt
    NS_HDR
    GET
    RES
    DEFERABLE = Yes, Label = L1
    msg0
    msg1
    msg2
    POST /client/L1
    POST /client/L1
    POST /client/L1
    data0
    data1
    final
    NetScaler Web 2.0 Push: HTTP Streaming Support
    NetScaler
    AppServer
    Client
    Messaging Bus
    V
    I
    P
    Labeling protocol
    Transaction Labeled.
    TCP connection can be optionally closed
    GET
    RES-HDR
    Quiet period. NS holding onto client connection.
    P
    U
    S
    H
    -
    V
    I
    P
    Quiet period. Waiting for next update.
    Chunk_0 (data)
    Quiet period. NS holding onto client connection.
    Quiet period. Waiting for next update.
    Chunk_1 (data)
    LastChunk (data)
  • Request from NetScaler to Server
    Request from Client (Browser) to NetScaler VIP
    Response from NetScaler VIP to Client (Browser)
    Response from Server to NetScaler
    Connection Labeling Protocol
    Client to Server
    Server to Client
  • NetScaler Push Updates
    Update from Server to Push VIP using REST API
    Update forwarded to Client by NetScaler
    Status Ack from NetScaler to Server in XML
  • Application code change for NetScaler Web 2.0 Push
    def longpoll_update(np, pushvs, label):
    holdtime = 10 + random.randint(0,5)
    time.sleep(holdtime)
    data = mesg % (label, holdtime)
    np.push_post_update(pushvs, label, data, True)
    def process_request():
    pushvs = os.environ.get('HTTP_NSPUSHVSERVER', '')
    if pushvs == '':
    print "Content-Type: text/html"
    print ""
    print "NetScaler PUSH functionality not enabled. "
    sys.exit()
    np = nspush.NsPushMgr()
    label = np.push_label_client()
    #daemonize this process, so the parent exits
    # and the long poll will send update later
    daemon.createDaemon()
    longpoll_update(np, pushvs, label)
    if __name__ == '__main__':
    process_request()
    class NsPushMgr:
    def push_label_client(self):
    label = str(int(time.time()))
    print "NSDEFERRABLE: YES"
    print "NSSERVERLABEL: ", label
    print "Content-Type: text/html"
    print ""
    return label
    def push_post_update(self, pushvip, label, data, msg_end):
    pushvip = re.sub('_', ':', pushvip)
    if msg_end is True:
    uri = '/CLIENT/V10/' + label + '?MSG_END=1'
    else:
    uri = '/CLIENT/V10/' + label + '?MSG_END=0'
    conn = httplib.HTTPConnection(pushvip)
    conn.request('POST', uri, data, {})
    resp = conn.getresponse()
    conn.close()
    poll.py
    nspush.py