tutorial slides - Ani's Homepage

advertisement
Tutorial – Summer 2007
CS 317: INTERNET COMPUTING
317 Summer 2007 - Tutorial
1
The Tutorial Session
 Total 6 weeks during the whole term.
 Two separate sessions
 1 hour duration each
 Each session twice a week.
 T1A - Tue, Thu – 12:30 t0 13:30
 T1B – Tue, Thu – 13:30 to 14:30
 T1C – (has been blocked)
317 Summer 2007 - Tutorial
2
Your TAs
 Anirban Sinha (you can call me Ani)
 Gitika Aggarwal
 Kan Cai
 We are all affiliated to the Distributed Systems
Research group under the supervision of separate
profs.
317 Summer 2007 - Tutorial
3
Tutorial Organization
 In strict correspondence with the
assignments.
 Three assignments, each of 2 weeks duration.
 Similarly, each of us will lead 2 weeks of the
tutorial .
 First two weeks, I will concentrate on the first
assignment.
 Next two weeks, Gitika will discuss the second
assignment.
 Last two weeks, Kan will help you out with the last
and final assignment.
317 Summer 2007 - Tutorial
4
What else to discuss?
 Questions related to the weekly quiz.
 Midterm questions and their solutions .
 Grading (only general ones)
 be careful to ask individual grading questions
offline.
 Debugging/testing/good practices.
317 Summer 2007 - Tutorial
5
What else to discuss?
 General queries/doubts/comments.
 We will try our best to answer the questions.
 If unable, we will answer it in the WebCT.
 Please try to attend the tutorial sessions.
 It will help you a lot in solving the assignments and
the quizzes.
 1% bonus for being there in the tutorial ! 
317 Summer 2007 - Tutorial
6
What not to discuss
 Direct solutions to assignments
 We have not solved the problems ourselves.
 Violation of UBC policies.
 What are the likely questions for
midterm/final/quizzes
 We are not mind readers – we do not know what
Dr. Vuong would like to give in the exams.
 Anything that is not related to 317- Canucks
game?!
 I would like to discuss that offline though 
317 Summer 2007 - Tutorial
7
What if I get stuck?!
 Use WEBCT discussion group!
 It is more likely that one of your peers has faced
the same problem and solved it!
 Group discussion helps to come up with a solution
together – much better than getting off-the-shelf
answer from the TAs.
 If totally stuck with no one knowing what to do,
Kan and possibly me will be there to help.
 Do *not* email problems to TAs individually
*unless* you really think its necessary.
317 Summer 2007 - Tutorial
8
Useful suggestions, tips …
 Read carefully the text and the lecture slides.
 Understand the basic concepts. Ask questions
if in doubt.
 Write small simple code to test out your
concepts – an excellent way to learn new
things.
 Know what is exactly being asked for.
 Don’t procastinate.
 Distribute the work over a longer period – helps
your mind to think and come up with ideas.
317 Summer 2007 - Tutorial
9
Useful suggestions, tips …
 If stuck, go back to the text and the lecture
slides – do not cry out for help at the first sign
of trouble.
 Talk to peers, help is not far away!
 Be patient and take a deep breath when
things go wrong.
317 Summer 2007 - Tutorial
10
End of Introduction
 Any questions, concerns, worries?
317 Summer 2007 - Tutorial
11
What you need for the
assignments?
 Single most important resource:
 Beej's Guide to Network Programming, Using
Internet Sockets.
http://beej.us/guide/bgnet/
 All you will ever need is there in this book.
 Study the examples and the network APIs
carefully.
317 Summer 2007 - Tutorial
12
Assignment 1: Proxy server
 Work in groups of three
 Smaller groups preferred but no bigger.
 15 hours total working time per team.
(excluding review time).
 If you have not read the assignment, here it is
in nutshell:
 Design a *caching* proxy server.
 Design a mechanism for cleaning expired items
from cache.
317 Summer 2007 - Tutorial
13
Assignment 1: Proxy server
 A proxy server works in between clients and
the web server.
 Helps several clients to share a single Internet
connection – cost effective.
 Also caches the requested pages so that
pages that are revisited can be delivered
immediately.
 Firewalls and IP filters are generally set up
along with the proxy servers.
317 Summer 2007 - Tutorial
14
Basic Socket Programming
 Client Side Programming:
 Call socket(): get a new client socket
 socket(PF_INET, SOCK_STREAM, 0): creates a new TCP/IP
socket.
 Fill in a structure with the server address & port:
 struct sockaddr_in their_addr
 Often we use gethostbyname() to obtain the remote
server IP from its host name.
317 Summer 2007 - Tutorial
15
Basic Socket Programming
 Client Side Programming:
 Connect() to the server.
 connect(sockfd, (struct sockaddr *)&their_addr, sizeof(struct
sockaddr)) : Connect to the remote client using the
client side socket, sockfd obtained through call to
socket() earlier.
 Start Receiving data:
 Call Recv(): recv(sockfd,
buf, MAXDATASIZE-1, 0),
where buf is the buffer where the data is received!
317 Summer 2007 - Tutorial
16
Basic Socket Programming
 Server Side Programming:
 Generally servers “bind” to a specific well-known
port. For example, all web-servers “bind” & then
“listen” on port 80.
 All clients (browsers) connect to this port by
default.
 Thus, server side programming involves a little
more work.
317 Summer 2007 - Tutorial
17
Basic Socket Programming
 Server Side Programming:
 Call Socket() to get a server side socket. Call is
identical as before.
 Fill in a structure as before.
 struct sockaddr_in my_addr
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(MYPORT);
my_addr.sin_addr.s_addr = INADDR_ANY;
memset(my_addr.sin_zero, '\0', sizeof my_addr.sin_zero);
 Fill in the structure with local port (MYPORT) and
local server address (INADDR_ANY).
317 Summer 2007 - Tutorial
18
Basic Socket Programming
 Server Side Programming:
 Call bind() : It will bind the server socket to the
specific port.
 This is done only on the server side, in order to
listen on a specific port.
 bind(sockfd, (struct sockaddr*)&my_addr, sizeof(struct sockaddr))
Here, sockfd is the socket file descriptor obtained from call to
socket() and my_addr is the same as discussed before.
317 Summer 2007 - Tutorial
19
Basic Socket Programming
 Server Side Programming:
 Now “listen” for connections from clients:
 listen(sockfd, BACKLOG), where backlog is the number of
outstanding connection requests to queue. Generally, its something
around 10 to 20 depending on the server load expected.
 Now “accept” new connections from clients.
 Accept() blocks (in general, unless you set the socket into
non-blocking mode) until a client connect()s to a server.
 It returns a new socked file descriptor for the
corresponding connection.
 Also fills a struct sockaddr_in with information about
the remote client address.
317 Summer 2007 - Tutorial
20
Basic Socket Programming
 Server Side Programming:
 There are two ways to deal with multiple incoming
client requests:
 Set the server side socket into non-blocking mode,
poll the socket at certain intervals for any
outstanding requests from clients and dispatch an
event handler to service the request – event driven
programming.
 Fork a new thread to service the request and the
main thread keeps accepting new connections in a
tight loop: Multithreaded programming.
317 Summer 2007 - Tutorial
21
Basic Socket Programming
 Server Side programming:
 Unless you really know event driven style, I would
suggest you to use multithreaded style
 Simpler to understand and code
 You are familiar with threaded programming already
from 213.
 The thread processing client requests can now
send() or recv() data from clients.
 If you really want to serve only one client, no need
of threads. Just one main thread can do all the
work.
317 Summer 2007 - Tutorial
22
Basic Socket Programming
 General APIs
 Close() and shutdown() : Used to de-allocate the socket
resources and shut down the connection.
 Gethostname() : get the local host name of the machine.
 fcntl(sockfd, F_SETFL, O_NONBLOCK): - set a socket in
non-blocking mode. More details on blocking issues in
the guide.
 setsockopt(listener,SOL_SOCKET,SO_REUSEADDR,&yes,si
zeof(int)) : to get rid of “address already in use message”
317 Summer 2007 - Tutorial
23
Basic Socket Programming –
Tips and Suggestions
 Read the APIs carefully.
 Use man pages when help is needed with APIs.
 Always check for return values and take
appropriate actions on errors.
 Work in steps – do not try to do everything all at
once.
 Use tools like telnet, ftp etc to test run your
program before proceeding to next steps.
317 Summer 2007 - Tutorial
24
Assignment 1: Proxy server
Basic Idea
 Create a server socket and listen for incoming
client request.
 When a new client connect()s, fork a new thread
to process the client request.
 Parse for remote server address from the client
request.
 Create a client socket and connect to the remote
server.
 Forward your client’s request to the remote
server. Send back response (separate threads?).
Keep doing it in a loop or terminate after one
iteration (?)
317 Summer 2007 - Tutorial
25
Assignment 1: Proxy server
Caching
 Cache requested pages. No need for
elaborate caching scheme.
 If requested page is already in cache, do not go to
the server.
 Terminate when either remote server or your
client disconnects.
317 Summer 2007 - Tutorial
26
Assignment 1: Proxy server
Cache Invalidation & Cleanup
 Objects in cache expire with time.
 Use a suitable mechanism to find expired items.
 Fork a new thread that cleans up expired
items from cache.
 The expired time limit is a command line
parameter that is provided by the user.
317 Summer 2007 - Tutorial
27
Discussion … (5/10/07)
 Concurrency Issues
 how many threads are needed?
 Caching Issues
 How to detect expired items?
 Persistent HTTP connection issues.
 How to detect a change in requested server
address etc …
 How robust should be your code?!
317 Summer 2007 - Tutorial
28
Discussion … (5/15/07)
 Tutorials T1A and T1B will probably be
combined into a single one …
 Any problems with anyone here?
 Any other administrative issues?
317 Summer 2007 - Tutorial
29
Discussion … (05/15/07)
 How’s things are with WebCT?
 Questions related to text (eg. prop & trans
delay)
 They are in the text itself!
 Besides TAs, you can ask Son the next day in class.
 Assignment 1 is due this Thursday
 Issues, problems, questions? ...
 Browser configuration (demo)
317 Summer 2007 - Tutorial
30
Discussion … (05/17/07)
 Tutorials T1A and T1B has been merged!
 Any conflicts?
 Do not forget to check the attendance sheet
in my homepage later and report any
inconsistencies immediately.
 Final set of updated slides will be posted
today.
 Gitika takes over from next week
 Will discuss assignment 2.
317 Summer 2007 - Tutorial
31
Discussion … (05/17/07)
 Assignment 1 is due next Tuesday, 22nd of May.
 No more discussion on Assignment 1 after today!
 I will try to grade Assignment 1 as soon as I can,
according to the guidelines provided by Son.
 Make sure you put the names of *all* group members




in the source code itself.
Use electronic handin – no written material.
All members of a group will be treated uniformly.
Be patient for the grades and comments.
I will try to be lenient.  yay!!!!
317 Summer 2007 - Tutorial
32
Discussion … (05/17/07)
 Grading (Assignment 1) …
 If you have questions on grading, you can send me
email directly (anirbans@cs.ubc.ca) BUT:
 Send all your questions in a single mail all at once.
 Only one mail per group will be answered.
 Write names, stud ID and CWL of all group members in
email.
 No later than 5 days after the grades/comments has been
sent out.
 Check instructor’s policy in the course webpage.
 Any response will follow the policy guidelines in the course
webpage.
317 Summer 2007 - Tutorial
33
Discussion … (05/17/07)
 Quiz 1 will be graded by all TAs together.
 Have patience.
 Any question on Quiz1 – ask any TA during the
tutorials.
 Grades will be posted in the WebCT as soon as
possible.
 That’s all from me!
 Any questions, comments??
317 Summer 2007 - Tutorial
34
Download