Python code test with screenshot needed
Python project/.DS_Store
Python project/.idea/.name
CNProject
Python project/.idea/CNProject.iml
Python project/.idea/misc.xml
Python project/.idea/modules.xml
Python project/.idea/vcs.xml
Python project/.idea/workspace.xml
1445461747316 1445461747316Python project/cdn ppt.pptx
CONTENT DELIVERY NETWORK
Submitted by:
Hongyi Guo,
Dimple Modugula,
Wentao Lu,
Scott Fontenarosa
Content Delivery Network -a system of computers networked together across internet that accelerates the delivery of WebPages , audio, video and other internet based content to the users around the world. CDN replicates the content provider’s files in servers.
THE COMPONENTS OF CDN
The origin server and a set of edge servers or cache servers
The request-routing component that is responsible for directing client requests to appropriate cache servers
Distribution component that moves contents from the origin server to the cache servers
Accounting component that maintains logs of client accesses and records he usage of CDN servers
TYPES OF SERVICES
Web Acceleration- CDN can increase the acceleration by pressing down the nodes in its own network
Streaming and Download-Video uses network bandwidth and coverage, and many customers use it for only CDN service streaming video for internet users
Hybrid CDN(Peer to Peer)-CDN requires peer to peer processing, the client requires software to be installed to the user or pre-installed on your computer decryption
Search Engine Optimization
Reservation for refusal- CDN technology provides redundancy for fail-safe protection on the internet.
TYPES OF CDN
Advantages for using CDN
Faster loading
Optimize live delivery
File mirroring
Minimize packet loss
Less pressure on hosting server
References
http://wwwusers.di.uniroma1.it/~novella/myhome/Home_Page_di_Novella_Bartolini/papers/CDN_tutorial.pdf
http://www.hit.bme.hu/~jakab/edu/litr/CDN/CDN-Taxonomy.pdf
http://www.webperformancetoday.com/2013/06/12/11-faqs-content-delivery-networks-cdn-web-performance/
https://en.wikipedia.org/wiki/Content_delivery_network
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1250586
THANK YOU
Python project/Client.py
__author__ = 'Tibbers' from Tkinter import * import tkMessageBox from PIL import Image, ImageTk import socket, threading, sys, traceback, os from RtpPacket import RtpPacket CACHE_FILE_NAME = "cache-" CACHE_FILE_EXT = ".jpg" class Client: INIT = 0 READY = 1 PLAYING = 2 state = INIT SETUP = 0 PLAY = 1 PAUSE = 2 TEARDOWN = 3 counter = 0 # Initiation.. def __init__(self, master, serveraddr, serverport, rtpport, filename): self.master = master self.master.protocol("WM_DELETE_WINDOW", self.handler) self.createWidgets() self.serverAddr = serveraddr self.serverPort = int(serverport) self.rtpPort = int(rtpport) self.fileName = filename self.rtspSeq = 0 self.sessionId = 0 self.requestSent = -1 self.teardownAcked = 0 self.connectToServer() self.frameNbr = 0 self.rtpSocket = socket.socket(socket.AF_INET,socket.SOCK_DGRAM) def createWidgets(self): """Build GUI.""" # Create Setup button self.setup = Button(self.master, width=20, padx=3, pady=3) self.setup["text"] = "Setup" self.setup["command"] = self.setupMovie self.setup.grid(row=1, column=0, padx=2, pady=2) # Create Play button self.start = Button(self.master, width=20, padx=3, pady=3) self.start["text"] = "Play" self.start["command"] = self.playMovie self.start.grid(row=1, column=1, padx=2, pady=2) # Create Pause button self.pause = Button(self.master, width=20, padx=3, pady=3) self.pause["text"] = "Pause" self.pause["command"] = self.pauseMovie self.pause.grid(row=1, column=2, padx=2, pady=2) # Create Teardown button self.teardown = Button(self.master, width=20, padx=3, pady=3) self.teardown["text"] = "Teardown" self.teardown["command"] = self.exitClient self.teardown.grid(row=1, column=3, padx=2, pady=2) # Create a label to display the movie self.label = Label(self.master, height=19) self.label.grid(row=0, column=0, columnspan=4, sticky=W+E+N+S, padx=5, pady=5) def setupMovie(self): """Setup button handler.""" if self.state == self.INIT: self.sendRtspRequest(self.SETUP) def exitClient(self): """Teardown button handler.""" self.sendRtspRequest(self.TEARDOWN) #self.handler() self.master.destroy() # Close the gui window os.remove(CACHE_FILE_NAME + str(self.sessionId) + CACHE_FILE_EXT) # Delete the cache image from video rate = float(self.counter/self.frameNbr) print '-'*60 + "\nRTP Packet Loss Rate :" + str(rate) +"\n" + '-'*60 sys.exit(0) def pauseMovie(self): """Pause button handler.""" if self.state == self.PLAYING: self.sendRtspRequest(self.PAUSE) def playMovie(self): """Play button handler.""" if self.state == self.READY: # Create a new thread to listen for RTP packets print "Playing Movie" threading.Thread(target=self.listenRtp).start() self.playEvent = threading.Event() self.playEvent.clear() self.sendRtspRequest(self.PLAY) def listenRtp(self): while True: try: data,addr = self.rtpSocket.recvfrom(20480) if data: rtpPacket = RtpPacket() rtpPacket.decode(data) print "||Received Rtp Packet #" + str(rtpPacket.seqNum()) + "|| " try: if self.frameNbr + 1 != rtpPacket.seqNum(): self.counter += 1 print '!'*60 + "\nPACKET LOSS\n" + '!'*60 currFrameNbr = rtpPacket.seqNum() #version = rtpPacket.version() except: print "seqNum() error" print '-'*60 traceback.print_exc(file=sys.stdout) print '-'*60 if currFrameNbr > self.frameNbr: # Discard the late packet self.frameNbr = currFrameNbr self.updateMovie(self.writeFrame(rtpPacket.getPayload())) except: # Stop listening upon requesting PAUSE or TEARDOWN print "Didn`t receive data!" if self.playEvent.isSet(): break # Upon receiving ACK for TEARDOWN request, # close the RTP socket if self.teardownAcked == 1: self.rtpSocket.shutdown(socket.SHUT_RDWR) self.rtpSocket.close() break def writeFrame(self, data): """Write the received frame to a temp image file. Return the image file.""" cachename = CACHE_FILE_NAME + str(self.sessionId) + CACHE_FILE_EXT try: file = open(cachename, "wb") except: print "file open error" try: file.write(data) except: print "file write error" file.close() return cachename def updateMovie(self, imageFile): """Update the image file as video frame in the GUI.""" try: photo = ImageTk.PhotoImage(Image.open(imageFile)) #stuck here !!!!!! except: print "photo error" print '-'*60 traceback.print_exc(file=sys.stdout) print '-'*60 self.label.configure(image = photo, height=288) self.label.image = photo def connectToServer(self): """Connect to the Server. Start a new RTSP/TCP session.""" self.rtspSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: self.rtspSocket.connect((self.serverAddr, self.serverPort)) except: tkMessageBox.showwarning('Connection Failed', 'Connection to \'%s\' failed.' %self.serverAddr) def sendRtspRequest(self, requestCode): """Send RTSP request to the server.""" #------------- # TO COMPLETE #------------- # Setup request if requestCode == self.SETUP and self.state == self.INIT: threading.Thread(target=self.recvRtspReply).start() # Update RTSP sequence number. # ... self.rtspSeq = 1 # Write the RTSP request to be sent. # request = ... request = "SETUP " + str(self.fileName) + "\n" + str(self.rtspSeq) + "\n" + " RTSP/1.0 RTP/UDP " + str(self.rtpPort) self.rtspSocket.send(request) # Keep track of the sent request. # self.requestSent = ... self.requestSent = self.SETUP # Play request elif requestCode == self.PLAY and self.state == self.READY: # Update RTSP sequence number. # ... self.rtspSeq = self.rtspSeq + 1 # Write the RTSP request to be sent. # request = ... request = "PLAY " + "\n" + str(self.rtspSeq) self.rtspSocket.send(request) print '-'*60 + "\nPLAY request sent to Server...\n" + '-'*60 # Keep track of the sent request. # self.requestSent = ... self.requestSent = self.PLAY # Pause request elif requestCode == self.PAUSE and self.state == self.PLAYING: # Update RTSP sequence number. # ... self.rtspSeq = self.rtspSeq + 1 # Write the RTSP request to be sent. # request = ... request = "PAUSE " + "\n" + str(self.rtspSeq) self.rtspSocket.send(request) print '-'*60 + "\nPAUSE request sent to Server...\n" + '-'*60 # Keep track of the sent request. # self.requestSent = ... self.requestSent = self.PAUSE # Resume request # Teardown request elif requestCode == self.TEARDOWN and not self.state == self.INIT: # Update RTSP sequence number. # ... self.rtspSeq = self.rtspSeq + 1 # Write the RTSP request to be sent. # request = ... request = "TEARDOWN " + "\n" + str(self.rtspSeq) self.rtspSocket.send(request) print '-'*60 + "\nTEARDOWN request sent to Server...\n" + '-'*60 # Keep track of the sent request. # self.requestSent = ... self.requestSent = self.TEARDOWN else: return # Send the RTSP request using rtspSocket. # ... # print '\nData sent:\n' + request def recvRtspReply(self): """Receive RTSP reply from the server.""" while True: reply = self.rtspSocket.recv(1024) if reply: self.parseRtspReply(reply) # Close the RTSP socket upon requesting Teardown if self.requestSent == self.TEARDOWN: self.rtspSocket.shutdown(socket.SHUT_RDWR) self.rtspSocket.close() break def parseRtspReply(self, data): print "Parsing Received Rtsp data..." """Parse the RTSP reply from the server.""" lines = data.split('\n') seqNum = int(lines[1].split(' ')[1]) # Process only if the server reply's sequence number is the same as the request's if seqNum == self.rtspSeq: session = int(lines[2].split(' ')[1]) # New RTSP session ID if self.sessionId == 0: self.sessionId = session # Process only if the session ID is the same if self.sessionId == session: if int(lines[0].split(' ')[1]) == 200: if self.requestSent == self.SETUP: #------------- # TO COMPLETE #------------- # Update RTSP state. print "Updating RTSP state..." # self.state = ... self.state = self.READY # Open RTP port. #self.openRtpPort() print "Setting Up RtpPort for Video Stream" self.openRtpPort() elif self.requestSent == self.PLAY: self.state = self.PLAYING print '-'*60 + "\nClient is PLAYING...\n" + '-'*60 elif self.requestSent == self.PAUSE: self.state = self.READY # The play thread exits. A new thread is created on resume. self.playEvent.set() elif self.requestSent == self.TEARDOWN: # self.state = ... # Flag the teardownAcked to close the socket. self.teardownAcked = 1 def openRtpPort(self): """Open RTP socket binded to a specified port.""" #------------- # TO COMPLETE #------------- # Create a new datagram socket to receive RTP packets from the server # self.rtpSocket = ... # Set the timeout value of the socket to 0.5sec # ... self.rtpSocket.settimeout(0.5) # try: # Bind the socket to the address using the RTP port given by the client user # ... # except: # tkMessageBox.showwarning('Unable to Bind', 'Unable to bind PORT=%d' %self.rtpPort) try: #self.rtpSocket.connect(self.serverAddr,self.rtpPort) self.rtpSocket.bind((self.serverAddr,self.rtpPort)) # WATCH OUT THE ADDRESS FORMAT!!!!! rtpPort# should be bigger than 1024 #self.rtpSocket.listen(5) print "Bind RtpPort Success" except: tkMessageBox.showwarning('Connection Failed', 'Connection to rtpServer failed...') def handler(self): """Handler on explicitly closing the GUI window.""" self.pauseMovie() if tkMessageBox.askokcancel("Quit?", "Are you sure you want to quit?"): self.exitClient() else: # When the user presses cancel, resume playing. #self.playMovie() print "Playing Movie" threading.Thread(target=self.listenRtp).start() #self.playEvent = threading.Event() #self.playEvent.clear() self.sendRtspRequest(self.PLAY)
Python project/Client.pyc
Python project/ClientLauncher.py
__author__ = 'Tibbers' import sys from Tkinter import Tk from Client import Client if __name__ == "__main__": try: serverAddr = sys.argv[1] serverPort = sys.argv[2] rtpPort = sys.argv[3] fileName = sys.argv[4] except: print "[Usage: ClientLauncher.py Server_name Server_port RTP_port Video_file]\n" root = Tk() # Create a new client #app = Client(root, serverAddr, serverPort, rtpPort, fileName) app = Client(root,serverAddr,serverPort,rtpPort,fileName) #app.master.title("RTPClient") app.master.title("RTPClient") root.mainloop()
Python project/Pseudocode.docx
Pseudocode
@ Client.py
def sendRtspRequest(requestCode)
if requestCode == SETUP && state == INIT
# Client establishs a TCP connection to the servers,typically on TCP port 554, the well-known port for RTSP
# Client will then commence issuing a series of RTSP header commands that have similar format to HTTP
> Describe the details of the session requirements to Server
> E.g the version of RTSP it supports
> The transport to be used for the data flow
> Any associated UDP or TCP port information
> These information is passed using the DESCRIBE and SETUP headers and is augment on the server response with a Session ID that the client and any transitory proxy devices, can use to identify the stream in future exchanges
# Once the negotiation parameters has been completed
> Client issue a PLAY command to instruct the server to commence delivery of the RTP data stream
# Once the client decides to close the stream, a TEARDOWN command is issued along with the Session ID instructing the server to cease the RTP delivery associated with that ID
Update RTSP sequence number
Problem:
ValueError: invalid literal for int() with base 10
problem of translate first 5 bits of file (frameLength) into integer
Python project/README.md
How to: Example: Open a terminal: python Server.py 1025 Open another terminal: python ClientLauncher.py 127.0.0.1 1025 5008 video.mjpeg Start the server with the command line python Server.py server_port Where server_port is the port your server listens to for incoming RTSP connections # 1025 # Standard RTSP port is 554 # But need to choose a #port > 1024 Open a new terminal Start the client with the command line python ClientLauncher.py server_host server_port RTP_port video_file Where # server_host : the name of the machine where server is running (here "127.0.0.1") Use command line hostname to get the hostname(IP address,human readable hostname may not work) # server_port : port the server is listening on (here "1025") # RTP_port : port where the RTP packets are received (here "5008") # video_file : name of video file you want to request,here "video.mjpeg" @ file format Lab`s` proprietary MJPEG(Motion JPEG) format # The server streams a video which has been encoded into a proprietary MJPEG file format # This format stores the video as concatenated JPEG-encoded images # Each image being preceded by a 5-Byte header which indicates the bit size of the image # Server parses the bitstream of MJPEG file to extract the JPEG images # Server sends the images to client at periodic intervals # Client then displays the individual JPEG images sent from server @ Client # Send RTSP commands to server by pressing buttons: > RTSP(Real Time Streaming Protocol) * A network control protocol designed for use in entertainment and communications system to control streaming media servers * Used for establishing and controlling media sessions between end points * Clients issue VCR-style commands e.g play, pause .. to facilitate real-time control of playback of media files from server # Most RTSP servers use the RTP(Real-time Transport Protocol) in conjunction with RTCP(Real-time Control Protocol) for media stream delivery. # Commands > SETUP * Send SETUP request to the server * Insert Transport header(specify port for RTP data socket you just created) * RTP : Real-time Transport Protocol * Read server`s` response * Parse Session header(from response) to get RTSP Session ID * Create a datagram socket for receiving RTP data * Set timeout on socket to 0.5 seconds > PLAY * Send PLAY request * Insert Session header * Use the Session ID(returned in the SETUP response) * Not put the Transport header in the request * Read the Server`s` response > PAUSE * Send PAUSE request * Insert the Session header * Use the Session ID returned in the SETUP response * Not put the Transport header in this request * Read the server`s` response > TEARDOWN * Send TEARDOWN request * Insert the Session header * Use the Session ID returned in the SETUP response * Not put the Transport header in this request * Read the server`s` response *** Must insert CSeq header in every request you send Which starts at 1 and incremented by one for each request you send What we need to implement @ Client.py # SETUP function # PLAY function # PAUSE function # TEARDOWN function @ RtpPacket.py # Set the RTP-version filed(V) = 2 # Set padding(P), extension(X), # of contributing sources(CC), and marker(M) fields => all to 0 # Set payload type field(PT). we use MJPEG type, type number is 26 # Set sequence number.(frameNbr argument) # Set timestamp (via Python time module) # Set source identifier(SSRC)(identifies the server,pick an ID you like) # We have no other contributing sources(field CC == 0), the CSRC-field does not exist. The packet header is 12 bytes
Python project/RtpPacket.py
__author__ = 'Tibbers' import sys from time import time # from VideoStream import VideoStream import VideoStream HEADER_SIZE = 12 class RtpPacket: #header = bytearray(HEADER_SIZE) #HEADER_SIZE = 12 def __init__(self): self.header = bytearray(HEADER_SIZE) def encode(self, version, padding, extension, cc, seqnum, marker, pt, ssrc, payload): """Encode the RTP packet with header fields and payload.""" timestamp = int(time()) print "timestamp: " + str(timestamp) self.header = bytearray(HEADER_SIZE) #-------------- # TO COMPLETE #-------------- # Fill the header bytearray with RTP header fields #RTP-version filed(V), must set to 2 #padding(P),extension(X),number of contributing sources(CC) and marker(M) fields all set to zero in this lab #Because we have no other contributing sources(field CC == 0),the CSRC-field does not exist #Thus the length of the packet header is therefore 12 bytes #Above all done in ServerWorker.py # ... #header[] = #header[0] = version + padding + extension + cc + seqnum + marker + pt + ssrc self.header[0] = version << 6 self.header[0] = self.header[0] | padding << 5 self.header[0] = self.header[0] | extension << 4 self.header[0] = self.header[0] | cc self.header[1] = marker << 7 self.header[1] = self.header[1] | pt self.header[2] = seqnum >> 8 self.header[3] = seqnum self.header[4] = (timestamp >> 24) & 0xFF self.header[5] = (timestamp >> 16) & 0xFF self.header[6] = (timestamp >> 8) & 0xFF self.header[7] = timestamp & 0xFF self.header[8] = ssrc >> 24 self.header[9] = ssrc >> 16 self.header[10] = ssrc >> 8 self.header[11] = ssrc # Get the payload from the argument # self.payload = ... self.payload = payload def decode(self, byteStream): """Decode the RTP packet.""" #print byteStream[:HEADER_SIZE] self.header = bytearray(byteStream[:HEADER_SIZE]) #temporary solved self.payload = byteStream[HEADER_SIZE:] def version(self): """Return RTP version.""" return int(self.header[0] >> 6) def seqNum(self): """Return sequence (frame) number.""" seqNum = self.header[2] << 8 | self.header[3] #header[2] shift left for 8 bits then does bit or with header[3] return int(seqNum) def timestamp(self): """Return timestamp.""" timestamp = self.header[4] << 24 | self.header[5] << 16 | self.header[6] << 8 | self.header[7] return int(timestamp) def payloadType(self): """Return payload type.""" pt = self.header[1] & 127 return int(pt) def getPayload(self): """Return payload.""" return self.payload def getPacket(self): """Return RTP packet.""" return self.header + self.payload
Python project/RtpPacket.pyc
Python project/Server.py
__author__ = 'Tibbers' import sys, socket from ServerWorker import ServerWorker class Server: def main(self): try: SERVER_PORT = int(sys.argv[1]) except: print "[Usage: Server.py Server_port]\n" rtspSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) rtspSocket.bind(('', SERVER_PORT)) print "RTSP Listing incoming request..." rtspSocket.listen(5) # Receive client info (address,port) through RTSP/TCP session while True: clientInfo = {} clientInfo['rtspSocket'] = rtspSocket.accept() # this accept {SockID,tuple object},tuple object = {clinet_addr,intNum}!!! ServerWorker(clientInfo).run() # Program Start Point if __name__ == "__main__": (Server()).main()
Python project/ServerWorker.py
__author__ = 'Tibbers' import random, math import time from random import randint import sys, traceback, threading, socket from VideoStream import VideoStream from RtpPacket import RtpPacket class ServerWorker: SETUP = 'SETUP' PLAY = 'PLAY' PAUSE = 'PAUSE' TEARDOWN = 'TEARDOWN' INIT = 0 READY = 1 PLAYING = 2 state = INIT OK_200 = 0 FILE_NOT_FOUND_404 = 1 CON_ERR_500 = 2 clientInfo = {} def __init__(self, clientInfo): self.clientInfo = clientInfo def run(self): threading.Thread(target=self.recvRtspRequest).start() def recvRtspRequest(self): """Receive RTSP request from the client.""" connSocket = self.clientInfo['rtspSocket'][0] while True: data = connSocket.recv(256) ### if data: print '-'*60 + "\nData received:\n" + '-'*60 self.processRtspRequest(data) def processRtspRequest(self, data): """Process RTSP request sent from the client.""" # Get the request type request = data.split('\n') line1 = request[0].split(' ') requestType = line1[0] # Get the media file name filename = line1[1] # Get the RTSP sequence number seq = request[1].split(' ') # Process SETUP request if requestType == self.SETUP: if self.state == self.INIT: # Update state print "SETUP Request received\n" try: self.clientInfo['videoStream'] = VideoStream(filename) self.state = self.READY except IOError: self.replyRtsp(self.FILE_NOT_FOUND_404, seq[1]) # Generate a randomized RTSP session ID self.clientInfo['session'] = randint(100000, 999999) # Send RTSP reply self.replyRtsp(self.OK_200, seq[0]) #seq[0] the sequenceNum received from Client.py print "sequenceNum is " + seq[0] # Get the RTP/UDP port from the last line self.clientInfo['rtpPort'] = request[2].split(' ')[3] print '-'*60 + "\nrtpPort is :" + self.clientInfo['rtpPort'] + "\n" + '-'*60 print "filename is " + filename # Process PLAY request elif requestType == self.PLAY: if self.state == self.READY: print '-'*60 + "\nPLAY Request Received\n" + '-'*60 self.state = self.PLAYING # Create a new socket for RTP/UDP self.clientInfo["rtpSocket"] = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.replyRtsp(self.OK_200, seq[0]) print '-'*60 + "\nSequence Number ("+ seq[0] + ")\nReplied to client\n" + '-'*60 # Create a new thread and start sending RTP packets self.clientInfo['event'] = threading.Event() self.clientInfo['worker']= threading.Thread(target=self.sendRtp) self.clientInfo['worker'].start() # Process RESUME request elif self.state == self.PAUSE: print '-'*60 + "\nRESUME Request Received\n" + '-'*60 self.state = self.PLAYING # Process PAUSE request elif requestType == self.PAUSE: if self.state == self.PLAYING: print '-'*60 + "\nPAUSE Request Received\n" + '-'*60 self.state = self.READY self.clientInfo['event'].set() self.replyRtsp(self.OK_200, seq[0]) # Process TEARDOWN request elif requestType == self.TEARDOWN: print '-'*60 + "\nTEARDOWN Request Received\n" + '-'*60 self.clientInfo['event'].set() self.replyRtsp(self.OK_200, seq[0]) # Close the RTP socket self.clientInfo['rtpSocket'].close() def sendRtp(self): """Send RTP packets over UDP.""" counter = 0 threshold = 10 while True: jit = math.floor(random.uniform(-13,5.99)) jit = jit / 1000 self.clientInfo['event'].wait(0.05 + jit) jit = jit + 0.020 # Stop sending if request is PAUSE or TEARDOWN if self.clientInfo['event'].isSet(): break data = self.clientInfo['videoStream'].nextFrame() #print '-'*60 + "\ndata from nextFrame():\n" + data + "\n" if data: frameNumber = self.clientInfo['videoStream'].frameNbr() try: #address = 127.0.0.1 #self.clientInfo['rtspSocket'][0][0] #port = '25000' #int(self.clientInfo['rtpPort']) #print '-'*60 + "\nmakeRtp:\n" + self.makeRtp(data,frameNumber) #print '-'*60 #address = self.clientInfo['rtspSocket'][1] #!!!! this is a tuple object ("address" , "") port = int(self.clientInfo['rtpPort']) prb = math.floor(random.uniform(1,100)) if prb > 5.0: self.clientInfo['rtpSocket'].sendto(self.makeRtp(data, frameNumber),(self.clientInfo['rtspSocket'][1][0],port)) counter += 1 time.sleep(jit) except: print "Connection Error" print '-'*60 traceback.print_exc(file=sys.stdout) print '-'*60 def makeRtp(self, payload, frameNbr): """RTP-packetize the video data.""" version = 2 padding = 0 extension = 0 cc = 0 marker = 0 pt = 26 # MJPEG type seqnum = frameNbr ssrc = 0 rtpPacket = RtpPacket() rtpPacket.encode(version, padding, extension, cc, seqnum, marker, pt, ssrc, payload) return rtpPacket.getPacket() def replyRtsp(self, code, seq): """Send RTSP reply to the client.""" if code == self.OK_200: #print "200 OK" reply = 'RTSP/1.0 200 OK\nCSeq: ' + seq + '\nSession: ' + str(self.clientInfo['session']) connSocket = self.clientInfo['rtspSocket'][0] connSocket.send(reply) # Error messages elif code == self.FILE_NOT_FOUND_404: print "404 NOT FOUND" elif code == self.CON_ERR_500: print "500 CONNECTION ERROR"
Python project/ServerWorker.pyc
Python project/Socket-Prog-Video-Stream-Assignment-v7.pdf
CS5390 – F15
Socket Programming: Video Streaming with RTSP and RTP In this project you will implement a streaming video server and client that communicate using the Real- Time Streaming Protocol (RTSP) and send data using the Real-time Transfer Protocol (RTP). Your task is to implement the RTSP protocol in the client and implement the RTP packetization in the server. We will provide you code that implements the RTSP protocol in the server, the RTP de-packetization in the client, and takes care of displaying the transmitted video.
1. Code Client, ClientLauncher The ClientLauncher starts the Client and the user interface which you use to send RTSP commands and which is used to display the video. In the Client class, you will need to implement the actions that are taken when the buttons are pressed. You do not need to modify the ClientLauncher module. ServerWorker, Server These two modules implement the server which responds to the RTSP requests and streams back the video. The RTSP interaction is already implemented and the ServerWorker calls methods from the RtpPacket class to packetize the video data. You do not need to modify these modules. RtpPacket This class is used to handle the RTP packets. It has separate methods for handling the received packets at the client side and you do not need to modify them. The Client also de-packetizes (decodes) the data and you do not need to modify this method. You will need to complete the implementation of video data RTPpacketization (which is used by the server). VideoStream This class is used to read video data from the file on disk. You do not need to modify this class.
2. Running the code After completing the code, you can run it as follows: First, start the server with the command python Server.py server_port where server_port is the port your server listens to for incoming RTSP connections. The standard RTSP port is 554, but you will need to choose a port number greater than 1024. Then, start the client with the command python ClientLauncher.py server_host server_port RTP_port video_file where server_host is the name of the machine where the server is running, server_port is the port where the server is listening on, RTP_port is the port where the RTP packets are received, and video_file is the name of the video file you want to request (we have provided one example file movie.Mjpeg). The file format is described in Appendix section. The client opens a connection to the server and pops up a window like this:
You can send RTSP commands to the server by pressing the buttons. A normal RTSP interaction goes as follows:
1. The client sends SETUP. This command is used to set up the session and transport parameters. 2. The client sends PLAY. This command starts the playback. 3. The client may send PAUSE if it wants to pause during playback. 4. The client sends TEARDOWN. This command terminates the session and closes the connection.
The server always replies to all the messages that the client sends. The code 200 means that the request was successful while the codes 404 and 500 represent FILE_NOT_FOUND error and connection error respectively. In this lab, you do not need to implement any other reply codes. For more information about RTSP, please see RFC 2326.
3. The Client Your first task is to implement the RTSP protocol on the client side. To do this, you need to complete the functions that are called when the user clicks on the buttons on the user interface. You will need to implement the actions for the following request types. When the client starts, it also opens the RTSP socket to the server. Use this socket for sending all RTSP requests.
SETUP • Send SETUP request to the server. You will need to insert the Transport header in which you specify the port for the RTP data socket you just created. • Read the server’s response and parse the Session header (from the response) to get the RTSP session ID. • Create a datagram socket for receiving RTP data and set the timeout on the socket to 0.5 seconds.
PLAY • Send PLAY request. You must insert the Session header and use the session ID returned in the SETUP response. You must not put the Transport header in this request. • Read the server's response.
PAUSE • Send PAUSE request. You must insert the Session header and use the session ID returned in the SETUP response. You must not put the Transport header in this request. • Read the server's response.
TEARDOWN • Send TEARDOWN request. You must insert the Session header and use the session ID returned in the SETUP response. You must not put the Transport header in this request. • Read the server's response.
Note: You must insert the CSeq header in every request you send. The value of the CSeq header is a number which starts at 1 and is incremented by one for each request you send.
Example Here is a sample interaction between the client and server. The client's requests are marked with C: and server's replies with S:. In this lab both the client and the server do not use sophisticated parsing methods, and they expect the header fields to be in the order you see below.
C: SETUP movie.Mjpeg RTSP/1.0 C: CSeq: 1 C: Transport: RTP/UDP; client_port= 25000
S: RTSP/1.0 200 OK S: CSeq: 1 S: Session: 123456
C: PLAY movie.Mjpeg RTSP/1.0 C: CSeq: 2 C: Session: 123456
S: RTSP/1.0 200 OK S: CSeq: 2 S: Session: 123456
C: PAUSE movie.Mjpeg RTSP/1.0 C: CSeq: 3 C: Session: 123456
S: RTSP/1.0 200 OK S: CSeq: 3 S: Session: 123456
C: PLAY movie.Mjpeg RTSP/1.0 C: CSeq: 4 C: Session: 123456
S: RTSP/1.0 200 OK S: CSeq: 4 S: Session: 123456
C: TEARDOWN movie.Mjpeg RTSP/1.0 C: CSeq: 5 C: Session: 123456
S: RTSP/1.0 200 OK S: CSeq: 5 S: Session: 123456
Client State One of the key differences between HTTP and RTSP is that in RTSP each session has a state. In this lab you will need to keep the client's state up-to-date. Client changes state when it receives a reply from the server according to the following state diagram.
4. The Server On the server side, you will need to implement the packetization of the video data into RTP packets. You will need to create the packet, set the fields in the packet header and copy the payload (i.e., one video frame) into the packet. When the server receives the PLAY-request from the client, the server reads one video frame from the file and creates an RtpPacket-object which is the RTP-encapsulation of the video frame. It then sends the frame to the client over UDP every 50 milliseconds. For the encapsulation, the server calls the encode function of the RtpPacket class. Your task is to write this function. You will need to do the following: (the letters in parenthesis refer to the fields in the RTP packet format below).
• Set the RTP-version field (V). You must set this to 2. • Set padding (P), extension (X), number of contributing sources (CC), and marker (M) fields. These are all set to zero in this lab. • Set payload type field (PT). In this lab we use MJPEG and the type for that is 26. • Set the sequence number. The server gives this the sequence number as the frameNbr argument to the encode function. • Set the timestamp using the Python’s time module. • Set the source identifier (SSRC). This field identifies the server. You can pick any integer value you like. • Because we have no other contributing sources (field CC == 0), the CSRC-field does not exist. The length of the packet header is therefore 12 bytes, or the first three lines from the diagram below.
You must fill in the header fields in the header bytearray of the RtpPacket class. You will also need to copy the payload (given as argument data) to the RtpPacket’s payload data field. The above diagram is in the network byte order (also known as big-endian). Python uses the same byte order, so you do not need to transform your packet header into the network byte order. For more details on RTP, please see RFC 1889. Twiddling the Bits Here are some examples on how to set and check individual bits or groups of bits. Note that in the RTP packet header format smaller bit-numbers refer to higher order bits, that is, bit number 0 of a byte is 2^7 and bit number 7 is 1 (or 2^0). In the examples below, the bit numbers refer to the numbers in the above diagram. Because the header-field of the RtpPacket class is of type bytearray, you will need to set the header one byte at a time, that is, in groups of 8 bits. The first byte has bits 0-7, the second byte has bits 8-15, and so on. To set bit number n in variable mybyte of type byte: mybyte = mybyte | 1 << (7 - n) To set bits n and n + 1 to the value of foo in variable mybyte: mybyte = mybyte | foo << (7 - n) Note that foo must have a value that can be expressed with 2 bits, that is, 0, 1, 2, or 3. To copy a 16-bit integer foo into 2 bytes, b1 and b2: b1 = (foo >> 8) & 0xFF b2 = foo & 0xFF After this, b1 will have the 8 high-order bits of foo and b2 will have the 8 low-order bits of foo. You can copy a 32-bit integer into 4 bytes in a similar way. Bit Example Suppose we want to fill in the first byte of the RTP packet header with the following values: V = 2 P = 0 X = 0 CC = 3 In binary this would be represented as 1 0 | 0 | 0 | 0 0 1 1 V=2 P X CC = 3 2^7 . . . . . . . . 2^0
5. Required Extensions In addition to the above, you are required to implement the following. Statistics Analysis Calculate statistics about the session. Statistics include RTP packet loss rate, video date rate (in bits of bytes per second), jitter and any other interesting statistics you can think of. To that end, you need to analyze the code and insert the necessary hooks to collect the data. If the client and server run on the same host, you will need to implement a process emulating the network impairments with settable RTP packet loss ratio, throughput and jitter. Three-Button User Interface The user interface on the RTPClient has 4 buttons for the 4 actions. If you compare this to a standard media player, such as RealPlayer or Windows Media Player, you can see that they have only 3 buttons for the same actions: PLAY, PAUSE, and STOP (roughly corresponding to TEARDOWN). There is no SETUP button available to the user. Given that SETUP is mandatory in an RTSP-interaction, how would you implement that in a media player? When does the client send the SETUP? Come up with a solution and implement it. Also, is it appropriate to send TEARDOWN when the user clicks on the STOP button?
6. Research Topics Write a research paper approximately seven to ten pages long about one of these topics. Make sure, you credit any source you use in your document. At least five references required. In the first phase, you are required to submit for approval a proposed outline listing the specific items in your paper before you work on the detailed paper to be submitted in the final team report. Below are the topics, along with some suggested items for the outline. You may include other items in your proposed outline, but they will have to be approved.
Content Delivery Networks. Suggested menu of possible items o Describe the needs that necessitated having these networks. o Describe common topology and schemes of servers. o Benefits of using CDNs. o Comparison of major companies’ solutions for CDN.
Netflix. Suggested menu of possible items o Describe the architecture of Netflix. o Explain how Netflix’s streaming platform works? o Give some insights about Dynamic Adaptive Streaming over HTTP (DASH). o CDN selection algorithm by Netflix.
FaceTime (this is about conversational video, not video streaming). Suggested menu of possible items
o Architecture o Background overview of SIP and RTP o How FaceTime uses SIP and RTP and SRTP o NAT traversal in FaceTime o Impact on traditional cellular networks' business models
7. What to Turn In 1. A proposed outline of the research paper for approval by date D1 2. A team report by date D2
a) Including the complete code for the four-button user interface and the three-button user interface. The complete code includes the pieces you modified or wrote and the pieces you did not have to modify.
b) Providing a background summary of RTP and RTSP and how they are utilized in streaming c) Describing your hardware setup and configuration d) Including the design document of your code e) Providing screenshots showing the user interface, three-button and four-button f) Providing results of the statistics analysis about the session: RTP packet loss rate, etc. g) Describing what issues, if any, the team encountered during the project, how the team overcame
the issues and what the team learned from the project. You can also provide suggestions on how the projects in Computer Networks could be improved in the future.
h) Including a video clip to demo the code running i) Including the research paper
3. Individual reports, one for each team member by date D2 a) If you, as an individual team member, have anything specific to add to 1.g) in the team report,
please do it in your individual report. Describe what issues, if any, you, as an individual team member, encountered during the project, how you overcame the issues and what you learned from the project (this is not necessarily just about the topic, could be related to teamwork, etc.). You can also provide suggestions on how the projects in Computer Networks could be improved in the future. This complements the team report with any individual viewpoint not included in the team report.
b) Describing what each team member (including yourself) did and contributed to the project 4. Powerpoint slides for the in-class presentation by date D2. The slides is a summary of the key points in the team report. The presentation should also include a demo of your code running. The demo could be a live demo or be based on the video clip. Aim for a 25-30 minute presentation including demo, to leave time for Q&A.
8. Appendix 1. Lab’s proprietary MJPEG (Motion JPEG) format In this lab, the server streams a video which has been encoded into a proprietary MJPEG file format. This format stores the video as concatenated JPEG-encoded images, with each image being preceded by a 5-Byte header which indicates the bit size of the image. The server parses the bitstream of the MJPEG file to extract the JPEG images on the fly. The server sends the images to the client at periodic intervals. The client then displays the individual JPEG images as they arrive from the server.
Python project/TeamReport.docx
CONTENT DELIVERY NETWORK
Submitted by:
Hongyi Guo,
Dimple Modugula,
Wentao Lu,
Scott Fontenarosa
CONTENTS PAGE NO
1.Introduction.........................................................................................3
2.Motivation for Content Delivery Network...........................................3
3.Types of Content and Services in a CDN............................................4
4.Content Delivery Network Architecture..............................................7
5.How CDN Works................................................................................10
6.Content Service Protocols...................................................................11
7.Content Delivery Service Providers.....................................................12
8.Video Stream Coding Part……………………………………………13
9.References............................................................................................24
1.INTRODUCTION
In today's world in order to cope with the increasing demands on performance, security and reliability, while at the same time reducing costs, the content delivery networks solution has been developed.
Content delivery networks provide:
1. an efficient way of distributing content to decentralised systems, guaranteeing consistency of information in a timely matter
2. an efficient way of directing requestors of information to the information source, which is the closest and most cost- effective for them to retrieve the information from and
3. a more efficient way to distribute content with the end goal of improving the user experience while accessing the information
Content Delivery Networks (CDN), evolved first in 1998, replicate contents over several mirrored web servers (i.e., surrogate servers) strategically placed at various locations in order to deal with the flash crowds. Geographically distributing the web servers’ facilities is a method commonly used by service providers to improve performance and scalability.
A content delivery network or content distribution network (CDN) is a large distributed system of proxy servers deployed in multiple data centers via the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance. CDNs serve a large fraction of the Internet content today, including web objects such as text, graphics and scripts, downloadable objects-media files, software, documents, applications-e-commerce, portals, live streaming media, on-demand streaming media, and social networks
2.MOTIVATION FOR CONTENT DELIVERY NETWORK
While content delivery networks also solve ancillary problems such as improving global availability and reducing bandwidth, the main problem they address is latency: the amount of time it takes for the host server to receive, process, and deliver on a request for a page resource (images, CSS files, etc.). Latency depends largely on how far away the user is from the server, and it’s compounded by the number of resources a web page contains.
CDNs facilitate faster page loads and offer other important benefits including the following advantages:
1.Eliminate Pauses and Accommodate Heavy Traffic
Video streaming often results in jitters and pauses due to lags in transmission times, but CDNs help to deliver better user experiences when downloading video and audio content.
2.Minimize Packet Loss
Users get improved streaming quality.
3.Faster Loading
Internet speeds improve, but people expect nearly instantaneous page loads. Faster load times increase sales according to many studies and a vast body of anecdotal evidence.
4.File Mirroring
File mirroring protects data if natural disasters affect certain areas of the Internet. Hurricanes and earthquakes could cause significant disruptions to services in key geographical area.
5.Optimize Live Delivery
The success of YouTube and social media sharing has made video extremely popular, and most businesses should consider adding video elements to their content.
Live events help to generate increased traffic.
Small organizations and schools can broadcast live events to strengthen SEO efforts.
Anyone can broadcast live networks of material as part of a marketing strategy.
6.Enable Linear Networks
Companies can broadcast in the same way that major networks do, creating their own program schedules for 24-hour CDN deliveries around the world.
7.Support Video on Demand
Organizations can enhance their online presence with video libraries, how-to videos, training programs and other marketing tools.
8.Scalability
New technology and advanced mobile applications place increasingly greater demands on servers, but large CDNs can handle new material as companies expand their online presences.
3.TYPES OF CONTENT AND SERVICES IN A CDN
Types of Content and Services in a CDN CDN providers host third party contents to fasten the delivery of any type of digital content, e.g. audio/video streaming media, html pages, images, formatted documents or applications. The content sources could be media companies, large enterprises, broadcasters, web/Internet service provider. Due to the heterogeneous nature of the content to be delivered, various architectures and technologies can be adopted to design and develop a CDN. We now analyze the characteristics of the content and of the applications that most likely take advantages of a CDN architecture.
– Static web based services. Used to access static content (static html pages, images, document, software patches, audio and/or video files) or content that change with low frequency or timely (volatile web pages, stock quote exchange). All CDN provider (Akamai Inc., Speedera Inc., AT&T inc., Globix Inc. just to mention some) support this type of content delivery. This 6 N. Bartolini, E. Casalicchio, and S. Tucci type of content can easily be cached and its freshness maintained at the edge using traditional content caching technologies.
– Web storage services. Essentially, this application can be based on the same techniques used for static content delivery. Additional features to manage logging and secure file transfer should be added. This type of application can require processing at the origin site or at the edge.
– File transfer services. World wide software distribution (patch, virus defi- nition, etc.), e-learning material from an enterprise to all their global employees, movies-on-demand from a large media company, highly detailed medical images that are shared between doctors and hospitals, etc. All these content types are essentially static and can be maintained using the same techniques adopted for static web services.
– E-commerce services. The semantic of the query used in browsing a product catalogue is not complex, so frequent query results can be successfully cached using traditional DB query caching techniques. Shopping charts can be stored and maintained at the replica server and also orders and credit card transactions can be processed at the edge: this requires trusted transaction-enabled replica servers. In the authors propose a framework for enabling dynamic content caching for e-commerce site.
– Web application. Web transactions, data processing, database access, calendars, work schedules, all these services are typically characterized by an application logic that elaborates the client requests producing as results a dynamic web page. A partial solution to the employment of a CDN infrastructure in presence of dynamic pages is to fill the replica servers with the content that most frequently composes the dynamically generated web pages, and maintaining the application and its processing activity that produces the dynamic pages at the origin server. Another approach is to replicate both the application (or a portion of it) and the content at the edge server. In this way all the content generation process (application logic and content retrieval) are handled by the replica server thus offloading the origin server
. – Directory services. Used for access to database servers. For example, in the case of a LDAP server, frequent query results or a subsets of directories can be cached at the edge. Traditional DB query caching techniques may be adopted.
– Live or on-demand streaming. In this case the edge server must have streaming capability
3.1 Streaming Media Content
Streaming media can be live and on-demand, thus a CDN needs to be able to deliver media in both these two modes. Live means that the content is delivered ”instantly” from the encoder to the media server, and then onto the media client. This is typically used for live events such as concerts or broadcasts. The end-to-end delay is at a minimum 20 seconds with today’s technologies, so ”live mode” is effectively ”semi real-time”. In on-demand, the content is encoded and then stored as streaming media files on media servers. The content is then available for request by media clients. This is typically used for content such as video or audio clips for later replay, e.g., video-on-demand, music clips, etc. A specialized server, called a media server, usually serves the digitalized and encoded content. The media server generally consists of media server software that runs on a general-purpose server. When a media client wishes to request a certain content, the media server responds to the query with the specific video or audio clip. The current product implementations of streaming servers are generally proprietary and demand that the encoder, server, and player all belong to the same vendor. Streaming servers also use specialized protocols (such as RTSP, RTP and MMS) for delivery of the content across the IP network. In streaming media CDNs a replica server must have, at least, the additional functionalities listed below.
– The ability to serve live content such as newscasts, concerts, or meetings etc. either in Multicast or Unicast mode.
– Support for delivery of stored or on-demand content such as training, archived meetings, news clips, etc.
– Caching capability of streaming media. Caching a large media file is unproductive, so typically media files are split in segment. Neighbor replica must be capable to share and exchange segment to minimize the network load and cache occupancy.
– Peering capability to exchange and retrieve content from the neighbor streaming cache in case of cache miss. Streaming cache node can be organized in a hierarchy.
– Media transcoding functionality, to adapt media streams for different client capabilities, e.g., low quality/bandwidth content to dial-up users, high quality/bandwidth to xDSL users.
– Streaming session handoff capability. The typically long life of a streaming session, in presence of user’s mobility, causes the need for midstream handovers of streaming session between replica servers.
3.2 Web Application
Accessing dynamic content and other computer applications is one of the major challenges in CDN. CDN supporting this kind of content and services are also called Application Content Delivery Networks (ACDN). Some providers like AppStream Inc. and PIVIA Inc., implement ACDN using the so called ”fat client” solution: the application is partitioned in ”streamlets” or special applets and sent to the client. The client receives enough code to start the application and execute it, the other parts of the application are sent on demand. These solution use patented and proprietary technologies. Another approach is to migrate the application to the edge server using general utility such as Ajasent and vMatrix. However application replication may be expensive especially if performed on demand. A completely different solution is to automatically deploy the application at the replica server.Authors define an ACDN architecture relying on standard technologies such as HTTP protocol, web servers, CGI/FastCGI scripts or servlets.
4. CONTENT DELIVERY NETWORK ARCHITECTURE
The main goal of server replication in a CDN is to avoid large amounts of data repeatedly traversing possibly congested links on the Internet. As Figure 1 shows, there are a variety of ways and scale (local area or wide area networks) in which content networks may be implemented. Local solutions are web clusters, that typically hosts single site, and web farms, typically used to host multiple sites. Wide area solutions include: distributed web server systems, used to host single or multiple sites; cooperative proxy cache networks (a service infrastructure to reduce latency in downloading web objects) and content delivery networks that are the focus of this paper.
A typical server farm is a group of servers, ranging from two to thousands, that makes use of a so-called cooperative dispatcher, working at OSI layers 4 and/or 7, to hide the distributed nature of the system, thus appearing as a single origin site. A layer 4 web switch dispatches the requests, among a group of servers, on the basis of network layer information such as IP address and TCP port. A content switch, working at the application layer, examines the content of requests and dispatches them among a group of servers. The goals of a server cluster/farm include: load-balancing of requests across all servers in the group; automatic routing of requests away from servers that fail; routing all requests for a particular user agent’s session to the same server, if necessary to preserve session state.
A type of content network that has been in use for several years is a caching proxy deployment. Such a network might typically be employed by an ISP for the benefit of narrow bandwidth users accessing the Internet. In order to improve performance and reduce bandwidth utilization, caching proxies are deployed close to the users. These users are encouraged to send their web requests through the caches rather than directly to origin servers, by configuring their browsers to do so. When this configuration is properly done, the user’s entire browsing session goes through a specific caching proxy. This way the proxy cache would contain the hot portion of content that is being viewed by all the users of that caching proxy. A provider that deploys caches in many geographically locations may also deploy regional parent caches to further aggregate user requests thus creating an architecture known as hierarchical caching. This may provide additional performance improvements and bandwidth savings. Using rich parenting protocols, redundant parents may be deployed such that a failure in a primary parent is detected and a backup is used instead. Using similar parenting protocols, requests may be partitioned such that requests for certain content domains are sent to a specific primary parent. This can help to maximize the efficient use of caching proxy resources. Clients may also be able to communicate directly with multiple caching proxies. Though certainly showing better scalability than a single origin server, both hierarchical caching and server farms have their limits. In these architectures, the replica servers are typically deployed in proximity to the origin server, therefore they do not introduce a significant improvement to the performance difficulties that are due to the network congestion. Caching proxies can improve performance difficulties due to congestion (since they are located in proximity to the final users) but they cache objects reactively to the client demand. Reactive caching based on client demand performs poorly if the requests for a given object, while numerous in aggregate, are spread among many different caching proxies. To address these limitations, CDNs employ a solution based on proactive rather than on reactive caching, where the content is prefetched from the origin server and not cached on demand. In a CDN, multiple replicas host the same content. A request from a browser for a single content item is directed to the replica that is considered the best suited at the moment of the request arrival, and the item is served to the client in a shorter time than the one it would have taken to fetch it from its origin server. Since static information about geographic locations and network connectivity are not sufficient to choose the best replica, a CDN typically incorporates dynamic information about network conditions and load on the replicas, to redirect requests and balance the load among the servers. Operating a CDN is therefore a complex and expensive activity. For this reason a CDN is typically built and operated by a network/service provider that offers a content distribution service to several content providers.
A content delivery architecture consists of a set of surrogate servers that deliver copies of content to the users while combining different activities (see figure 2).
– the request-routing infrastructure consists of mechanisms to redirect content requests from a client to a suitable surrogate.
– the distribution infrastructure consists of mechanisms to move contents from the origin server to the surrogates.
– the accounting infrastructure tracks and collects data on request-routing, distribution, and delivery functions within the CDN creating logs and reports of distribution and delivery activities.
The origin server (hosting the content to be delivered) interacts with the CDN in two ways (see figure 2):
– it pushes new content to the replica servers, (the replica themselves request content updates from the origin server through the distribution infrastructure);
– it requests logs and other accounting data from the CDN or the CDN itself provides this data to the origin server through the accounting infrastructure.
The clients interact with the CDN through the request routing infrastructure and surrogate servers. Figure 2 shows one of the possible scenarios of interaction between the clients, the access routers, the replica servers and the origin server. The user agent sends (1) a content request to the routing infrastructure, that redirects (2) the client request to a surrogate server, to which the client subsequently asks (3) the desired content.
5.HOW CDN WORKS
Content delivery networks (CDNs) are an important part of Internet infrastructure that are frequently used without a full understanding of what’s happening behind the scenes.
When a web browser makes a request for a resource, the first step is to make a DNS request. The browser gives the domain name and expects to receive an IP address back. With the IP address, the browser can then contact the web server directly for subsequent request.
Physics determines how fast one computer can contact another over physical connections, and so attempting to access a server in China from a computer in the United States will take longer than trying to access a U.S. server from within the U.S. To improve user experience and lower transmission costs, large companies set up servers with copies of data in strategic geographic locations around the world. This is called a CDN, and these servers are called edge servers, as they are closest on the company’s network to the end-user.
DNS resolution
When the browser makes a DNS request for a domain name that is handled by a CDN, there is a slightly different process than with small, one-IP sites. The server handling DNS requests for the domain name looks at the incoming request to determine the best set of servers to handle it. At it’s simplest, the DNS server does a geographic lookup based on the DNS resolver’s IP address and then returns an IP address for an edge server that is physically closest to that area. So if I’m making a request and the DNS resolver I’m routed to is Virginia, I’ll be given an IP address for a server on the East coast; if I make the same request through a DNS resolver in California, I’ll be given an IP address for a server on the West coast. You may not end up with a DNS resolver in the same geographic location from where you’re making the request.
That’s the first step of the process: getting the request to the closest server possible. Keep in mind that companies may optimize their CDNs in other ways as well, for instance, redirecting to a server that is cheaper to run or one that is sitting idle while another is almost at capacity. In any case, the CDN smartly returns the best possible IP address to handle the request.
Accessing content
Edge servers are proxy caches that work in a manner similar to the browser caches. When a request comes into an edge server, it first checks the cache to see if the content is present. The cache key is the entire URL including query string (just like in a browser). If the content is in cache and the cache entry hasn’t expired, then the content is served directly from the edge server.
If, on the other hand, the content is not in the cache or the cache entry has expired, then the edge server makes a request to the origin server to retrieve the information. The origin server is the source of truth for content and is capable of serving all of the content that is available on the CDN. When the edge server receives the response from the origin server, it stores the content in cache based on the HTTP headers of the response.
Yahoo! created and open sourced the Apache Traffic Server, which is what Yahoo! uses in its CDN for managing this traffic. Reading through the Traffic Server documentation is highly recommended if you’d like to learn more about how cache proxies work.
6.CONTENT SERVICE PROTOCOLS
Several protocol suites are designed to provide access to a wide variety of content services distributed throughout a content network. The Internet Content Adaptation Protocol(ICAP) was developed in the late 1990s to provide an open standard for connecting application servers. A more recently defined and robust solution is provided by the Open Pluggable Edge Services (OPES) protocol. This architecture defines OPES service applications that can reside on the OPES processor itself or be executed remotely on a Callout Server. Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly. It is fairly common for websites to have generated content. It could be because of changing content like catalogs or forums, or because of the personalization. This creates a problem for caching systems. To overcome this problem a group of companies created ESI.
Peer-to-peer CDNs
In peer-to-peer (P2P) content-delivery networks, clients provide resources as well as use them. This means that unlike client-server systems, the content centric networks can actually perform better as more users begin to access the content (especially with protocols such as Bittorrent that require users to share). This property is one of the major advantages of using P2P networks because it makes the setup and running costs very small for the original content distributor.
Private CDNs
If content owners are not satisfied with the options or costs of a commercial CDN service, they can create their own CDN. This is called a private CDN. A private CDN consists of POPs that are only serving content for their owner. These POPs can be caching servers, reverse proxies or application delivery controllers. It can be as simple as two caching servers or large enough to serve petabytes of content.
CDN trends
Emergence of telco CDNs
The rapid growth of streaming video traffic uses large capital expenditures by broadband providers in order to meet this demand and to retain subscribers by delivering a sufficiently good quality of experience.
To address this, telecommunications service provider (TSPs) have begun to launch their own content delivery networks as a means to lessen the demands on the network backbone and to reduce infrastructure investments.
7.CONTENT DELIVERY SERVICE PROVIDERS
Commercial CDNs
Akamai Technologies
Cloud Fare
Amazon CloudFront and many more
Telco CDNs
At&T
Bharati Airtel
Level 3 Communicatins.. etc.
8.Video Stream Coding Part
The Program includes 5 files:
Client.py
ClientLauncher.py
RtpPacket.py
Server.py
ServerWorker.py
What we will do is
1.Run Server.py on Server Terminal to start server:
E.g.
python Server.py server_port
server_port is the port your server listens to for incoming RTSP connections
# we can give it the value 1025
# Standard RTSP port is 554
# In this project we shall make the value > 1024
2.Run ClientLauncher.py on Client Terminal to start a client:
E.g
python ClientLauncher.py server_host server_port PRT_port video_file
server_host is the IP address of local machine (we can use “127.0.0.1” )
server_port is the port the server is listening on (here “1025”)
RTP_port is the port where RTP packets are received (here “5008”)
video_file is the name of video file that we want to play (here “video.mjpeg”)
RTSP
Real Time Streaming Protocol
For entertainment and communications systems to control streaming media servers
Establishing and controlling media sessions between end points
It uses TCP
RTP
Real-time Transport Protocol
Network protocol for delivering audio and video over IP Networks
It uses UDP
How RTSP and RTP work together?
What will be sent from client to server via RTSP Protocol are the commands like
SETUP
PLAY
PAUSE
TEARDOWN
These commands will let server side know what is next action it should complete.
What will be replied from server to client via RTSP Protocol are the parameters like:
OK_200
FILE_NOT_FOUND_404
CON_ERR_500
To tell the client if the server receive its commands correctly
After client receives server`s reply, it will change its state accordingly to :
READY
PLAYING
If SETUP command was sent from client to server
The “SETUP” RTSP Packet will include
1. SETUP command
2.Video file name to be play
3.RTSP Packet Sequence Number starts from 1
4.Protocol type: RTSP/1.0 RTP
5.Transmission Protocol: UDP
6.RTP Port for video stream transmission
When Server side receives “SETUP” command ,it will
1.Assign the client a Specific Session Number randomly
2.If something wrong with this command or server`s state,it will reply ERROR packet back to client
3.If command correct
The server will open the video file specified in the SETUP Packet and Initialize its video frame number to 0
3.If command processes correctly, it will reply OK_200 back to client and set its STATE to READY
The Client side will loop to receive Server`s RTSP Reply
Then Parse the RTSP Relpy Packet:
Get the Session Number
And if the Reply Packet is respond for the SETUP command
The client will set its STATE as READY
Then open a Rtp Port to receive incoming video stream
Afterward
If PLAY RTSP command was sent from client to server:
The Server will create a Socket for RTP transmission via UDP, and start a tread to send video stream packet
VideoStream.py will help chop the video file to separate frame , and put each frame into RTP data packet
Each data packet will also be encoded with a header, the header will include
RTP-version filed
Padding
extension
Contributing source
Marker
Type Field
Sequence Number
Timestamp
SSRC
they have been inserted in the RTP Packet via bitwise operations
Finally the RTP Packet will include a header and a video frame be sent to the RTP Port on the client side:
Then Client decode the RTP Packet to get the header and the video frame, reorganize the frames and display on the UI
If a PAUSE command was sent from client to server , it will stop the server from sending video frames to client
If a TEARDOWN command was sent from client to server, it will also stop the server from sending video frames to client and close the client terminal as well
8.REFERENCES
1. http://wwwusers.di.uniroma1.it/~novella/myhome/Home_Page_di_Novella_Bartolini/papers/CDN_tutorial.pdf
2. http://www.hit.bme.hu/~jakab/edu/litr/CDN/CDN-Taxonomy.pdf
3. http://www.webperformancetoday.com/2013/06/12/11-faqs-content-delivery-networks-cdn-web-performance/
4. https://en.wikipedia.org/wiki/Content_delivery_network
5. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1250586
2
Python project/test.sh
#!/bin/sh python Server.py 1025 python ClientLauncher.py 127.0.0.1 1025 5008 video.mjpeg
Python project/Video Stream Programming Report_Hongyi Guo.docx
Video Stream Programming Report
The Program includes 5 files:
Client.py
ClientLauncher.py
RtpPacket.py
Server.py
ServerWorker.py
What we will do is
1.Run Server.py on Server Terminal to start server:
E.g.
python Server.py server_port
server_port is the port your server listens to for incoming RTSP connections
# we can give it the value 1025
# Standard RTSP port is 554
# In this project we shall make the value > 1024
2.Run ClientLauncher.py on Client Terminal to start a client:
E.g
python ClientLauncher.py server_host server_port PRT_port video_file
server_host is the IP address of local machine (we can use “127.0.0.1” )
server_port is the port the server is listening on (here “1025”)
RTP_port is the port where RTP packets are received (here “5008”)
video_file is the name of video file that we want to play (here “video.mjpeg”)
RTSP
Real Time Streaming Protocol
For entertainment and communications systems to control streaming media servers
Establishing and controlling media sessions between end points
It uses TCP
RTP
Real-time Transport Protocol
Network protocol for delivering audio and video over IP Networks
It uses UDP
How RTSP and RTP work together?
What will be sent from client to server via RTSP Protocol are the commands like
SETUP
PLAY
PAUSE
TEARDOWN
These commands will let server side know what is next action it should complete.
What will be replied from server to client via RTSP Protocol are the parameters like:
OK_200
FILE_NOT_FOUND_404
CON_ERR_500
To tell the client if the server receive its commands correctly
After client receives server`s reply, it will change its state accordingly to :
READY
PLAYING
If SETUP command was sent from client to server
The “SETUP” RTSP Packet will include
1. SETUP command
2.Video file name to be play
3.RTSP Packet Sequence Number starts from 1
4.Protocol type: RTSP/1.0 RTP
5.Transmission Protocol: UDP
6.RTP Port for video stream transmission
When Server side receives “SETUP” command ,it will
1.Assign the client a Specific Session Number randomly
2.If something wrong with this command or server`s state,it will reply ERROR packet back to client
3.If command correct
The server will open the video file specified in the SETUP Packet and Initialize its video frame number to 0
3.If command processes correctly, it will reply OK_200 back to client and set its STATE to READY
The Client side will loop to receive Server`s RTSP Reply
Then Parse the RTSP Relpy Packet:
Get the Session Number
And if the Reply Packet is respond for the SETUP command
The client will set its STATE as READY
Then open a Rtp Port to receive incoming video stream
Afterward
If PLAY RTSP command was sent from client to server:
The Server will create a Socket for RTP transmission via UDP, and start a tread to send video stream packet
VideoStream.py will help chop the video file to separate frame , and put each frame into RTP data packet
Each data packet will also be encoded with a header, the header will include
RTP-version filed
Padding
extension
Contributing source
Marker
Type Field
Sequence Number
Timestamp
SSRC
they have been inserted in the RTP Packet via bitwise operations
Finally the RTP Packet will include a header and a video frame be sent to the RTP Port on the client side:
Then Client decode the RTP Packet to get the header and the video frame, reorganize the frames and display on the UI
If a PAUSE command was sent from client to server , it will stop the server from sending video frames to client
Python project/video.mjpeg
Python project/video3.mjpeg
Python project/videoClip.mov
Python project/VideoStream.py
__author__ = 'Tibbers' import struct class VideoStream: def __init__(self, filename): self.filename = filename try: self.file = open(filename, 'rb') print '-'*60 + "\nVideo file : |" + filename + "| read\n" + '-'*60 except: print "read " + filename + " error" raise IOError self.frameNum = 0 def nextFrame(self): """Get next frame.""" data = self.file.read(5) # Get the framelength from the first 5 bytes #data_ints = struct.unpack('<' + 'B'*len(data),data) data = bytearray(data) data_int = (data[0] - 48) * 10000 + (data[1] - 48) * 1000 + (data[2] - 48) * 100 + (data[3] - 48) * 10 + (data[4] - 48)# = #int(data.encode('hex'),16) final_data_int = data_int if data: framelength = final_data_int#int(data)#final_data_int/8 # xx bytes # Read the current frame frame = self.file.read(framelength) if len(frame) != framelength: raise ValueError('incomplete frame data') #print "frame length" #print len(frame) #if not (data.startswith(b'\xff\xd8') and data.endswith(b'\xff\xd9')): # raise ValueError('invalid jpeg') self.frameNum += 1 print '-'*10 + "\nNext Frame (#" + str(self.frameNum) + ") length:" + str(framelength) + "\n" + '-'*10 return frame def frameNbr(self): """Get frame number.""" return self.frameNum