📄 faq.html

📁 this gives details of the network programming
💻 HTML
字号:
<HTML><HEAD><TITLE>NetProg Homework 5 FAQ</TITLE><LINK rel=stylesheet type="text/css" HREF=../../style/proj.css></HEAD><BODY BGCOLOR=WHITE MARGINHEIGHT=0 MARGINWIDTH=0 TOPMARGIN=0  LEFTMARGIN=0><TABLE bgColor=#8899aa border=0 cellPadding=4 cellSpacing=0 width="100%">  <TR>    <TD class=title>&nbsp NetProg 2002 HW5 FAQ</TD> </TR><TR BGCOLOR=BLACK><TD CLASS=menu> &nbsp &nbsp<A CLASS=menu HREF=p5.html>Project Description</A> &nbsp &nbsp |&nbsp &nbsp<A CLASS=menu HREF=../submission.html>Submission Instructions</A></TD></TR><TR BGCOLOR=gray><TD CLASS=menu> &nbsp &nbsp<A CLASS=menu HREF=#errno>Solaris and errno</A> &nbsp &nbsp | &nbsp &nbsp<A CLASS=menu HREF=#out>Server Output</A> &nbsp &nbsp | &nbsp &nbsp<A CLASS=menu HREF=#concur>Excessive concurrency</A> &nbsp &nbsp | &nbsp &nbsp<A CLASS=menu HREF=#forking>Forking</A> &nbsp &nbsp | &nbsp &nbsp<A CLASS=menu HREF=#lock>Locking and accept</A></TD></TR><TR BGCOLOR=gray><TD CLASS=menu> &nbsp &nbsp <A CLASS=menu HREF=#exit>fork and thread errors</A> &nbsp &nbsp | &nbsp &nbsp<A CLASS=menu HREF=#ab>extra stuff from ab</A> </TD></TR></TABLE><BR><BR><DIV CLASS=page><CENTER><TABLE WIDTH=90% CELLPADDING=3 BORDER=0 CELLSPACING=0><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label<A NAME=errno> Question:</A></TD>  <TD CLASS=qa><P>On Solaris using pthreads and gcc, don't we need to compile  with -D_REENTRANT so that each thread has it's own copy of errno ? </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>Yes, you do need this on Solaris when using  pthreads. You should compile with something like this:</P> <CENTER>  <PRE>gcc -Wall -o hw5 -D_REENTRANT hw5.c -lsocket -lnsl -lpthread</PRE> </CENTER>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=out> Question:</A></TD>  <TD CLASS=qa><P>Should our server print something out each time it  handles a request? </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>No! This will slow down your server and your  measurements will be way off. Don't print anything in the server  (when everything is working fine).</P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=concur> Question:</A></TD>  <TD CLASS=qa><P>There seems to be something wrong with my server  that is messing up the entire machine it is running on. If I run ab  with thousands of requests and client concurrency of 100 the machine slows to a crawl and my  server doesn't seem to be reachable. What's wrong with my server? </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>You are probably overloading the machine, not your  server. You are, in fact, generating a SYN attack on the machine  hosting your server by telling ab to use such a high concurrency  level. I'd suggest using much smaller numbers - we don't have  high-end machines hosting our programs so we can't expect them to be  able to handle that much of a pounding. </P> <P>My suggestions: use server concurrency up to 10 or 20, and use client concurrency no more than about twice the server concurrency. Don't go near client concurrency of 100 for very long (very many requests total)! </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=forking>Question:</A></TD>  <TD CLASS=qa><P>Say you pre-fork 10 processes, and then you issue 20 requests, should  the server handle the last 10 requests sequentially, or should the  server always make sure there are 10 pre-forked processes, so on the  11th request it would fork off 10 more processes. It seems strange  to only handle the first 10 requests concurrently and then have  everything else handled sequentially. </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>Each of your processes should be an iterative  server, so they should be able to handle more than once  request. </P>  <P>Since the parent process doesn't have anything to  do in this kind of arrangement, you can just fork 9 times and then  have the parent also become an iterative server (for a total of 10).  </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=lock>Question:</A></TD>  <TD CLASS=qa><P>Do we need to use locking around calls to accept()? </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>No. The version of Solaris on the CS machines does  handles calls to accept fine, you do not need to ensure that only  one process/thread is calling accept at a time. </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=exit> Question:</A></TD>  <TD CLASS=qa><P>You mentioned in class that we can exit if fork() or  pthread_create() returns an error, what is the issue again? </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>In general it is very difficult to recover from  these kinds of problems and continue on. The issue is that I don't   want people experimenting with ways to recover from a failure to  fork() or pthread_create(), since it is easy to generate forking  loops (or loops that keep creating or trying to create threads) and  this could make the machine unusable for everyone else... </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label><A NAME=ab> Question:</A></TD>  <TD CLASS=qa><P>The ab program seems to connect to my server more  times than I expect, even if I only ask for one request it connects  more than once, what's up with that?  </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P>I understand why it happens for concurrency levels  greater than one - ab is blasting away at the concurrency level  requested until it has completed the desired total number of  requests. One it is done it shuts down any remaining connections  (keep in mind that ab doesn't know which ones will complete  first).</P>  <P>I don't understand why this also seems to happen when the  concurrency is set to 1, but it happens (I get 2 connections from  ab when I use <CODE>ab -n 1 -c 1</CODE>). This should not cause any  problem for your server... </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><!--<TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR><TR BGCOLOR=#ddeeff>  <TD VALIGN=TOP CLASS=label>Question:</TD>  <TD CLASS=qa><P> </P>  </TD></TR><TR BGCOLOR=#ffeedd>  <TD VALIGN=TOP CLASS=label>Answer:</TD>  <TD CLASS=qa><P> </P>  </TD></TR><TR><TD COLSPAN=2><BR> <HR WIDTH=80%><BR></TD></TR>--></TABLE></CENTER></DIV></BODY></HTML>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -