From grr Wed Jan 31 12:10:56 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id MAA20251; Wed, 31 Jan 1996 12:10:01 -0500 (EST) Date: Wed, 31 Jan 1996 12:10:01 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199601311710.MAA20251@ector.cs.purdue.edu> To: ttd Subject: Re: project1 C++/C question Cc: 603, grr Status: R Content-Length: 533 > Hi Gustavo, > > Is there any special reason to make the source look like C++? After all, the > libraries we use and the use of our code are presumably in/from C. Are we > allowed to "translate" the handout to C and use C from then on? > > Thanks! > >Tzvetan. > No, there is no special reason why the sources are in C++. You can translate them to C if you want to. Personally I feel more comfortable using C++. Maybe programming the second part of the project will be simplified and more structured using classes. --Gustavo From grr Thu Feb 1 15:52:29 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id PAA22142; Thu, 1 Feb 1996 15:51:36 -0500 (EST) Date: Thu, 1 Feb 1996 15:51:36 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012051.PAA22142@ector.cs.purdue.edu> To: ttd Subject: Re: read/write, send/recv problems Cc: 603, grr Status: RO Content-Length: 932 > It seems that tracing the read/write calls in talking-intensive applications > (like Netscape) generates too much output to stderr which eventually blocks the > application and even the X server. We suggest we add a #define switch which > allows tracing/no_tracing of read/write and send/recv calls. In simple > applications (like finger) read/write calls can be traced without problems. Be careful tracing write calls. If you trace write calls, socktrace itself may call "write" to trace "write" calls, causing infinite recursion. Anyway, you are not required to trace read/writes. If you trace them I would say that there should be a run time option in socktrace to enable this feature, otherwise it may flood the screen with information.. Your program at least should trace the following socket calls: socket, socketpair, listen, shutdown, setsockopt, send, receive, getsockopt, bind, connect, and accept. --Gustavo From grr Thu Feb 1 16:04:07 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA23466; Thu, 1 Feb 1996 16:02:57 -0500 (EST) Date: Thu, 1 Feb 1996 16:02:57 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012102.QAA23466@ector.cs.purdue.edu> To: 603, grr, psk Subject: Socket calls to trace Status: O Content-Length: 307 A more complete list of calls that you at least have to trace is: socket(), socketpair(), listen(), shutdown(), setsockopt(), send(), getsockopt(), bind(), connect(), accept(), getpeername(), getsockname(), recv(), recvfrom(), recvmsg(), sendmsg(), sendto(), setpeername(), and setsockname(). --Gustavo From grr Thu Feb 1 16:07:26 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA23829; Thu, 1 Feb 1996 16:06:39 -0500 (EST) Date: Thu, 1 Feb 1996 16:06:39 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012106.QAA23829@ector.cs.purdue.edu> To: 603, fresko, grr Subject: Re: read/write, send/recv problems Status: O Content-Length: 278 Gustavo> Your program at least should trace the following socket calls: Gustavo> socket, socketpair, listen, shutdown, setsockopt, send, receive, Gustavo> getsockopt, bind, connect, and accept. Nedim> No select? You can trace select, read, write if you want to. --Gustavo From grr Thu Feb 1 16:10:55 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA24109; Thu, 1 Feb 1996 16:10:08 -0500 (EST) Date: Thu, 1 Feb 1996 16:10:08 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012110.QAA24109@ector.cs.purdue.edu> To: 603, grr, ttd Subject: Re: read/write, send/recv problems Content-Length: 636 >> >> Anyway, you are not required to trace read/writes. If you trace them I would >>say that there should be a run time option in socktrace to enable this feature, >>otherwise it may flood the screen with information.. >> > >I'd really appreciate a suggestion how to incorporate this runtime option into >our library. There doesn't seem to be any way to access any environment >variable, for instance, and a command-line argument (to what?) is also out of >question... > You can pass run time options to socktracelib.so using an environment variable. socktracelib.so can get the environment variables calling "getenv()". --Gustavo From grr Thu Feb 1 16:15:13 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA24504; Thu, 1 Feb 1996 16:14:31 -0500 (EST) Date: Thu, 1 Feb 1996 16:14:31 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012114.QAA24504@ector.cs.purdue.edu> To: 603, grr, psk Subject: Re: Socket calls to trace Content-Length: 371 > Though in my earlier list I have given setpeername, I dont seem to find it in > man pages !! I don't know why setpeername is not public. Don't include it in the calls you trace. > and is there any special resoon why you excluded select No. Only that select did not seem to me that is a socket call. You can add it to your implementation if you want to. --Gustavo From grr Thu Feb 1 16:23:32 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA25186; Thu, 1 Feb 1996 16:22:41 -0500 (EST) Date: Thu, 1 Feb 1996 16:22:41 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012122.QAA25186@ector.cs.purdue.edu> To: 603, grr, psk Subject: Re: Socket calls to trace Status: R Content-Length: 171 > I would like to add "setsockname" also to this man page less list. > > --psk Exclude both setsockname() setpeername() from the list of calls to be traced. --Gustavo From grr Thu Feb 1 16:32:18 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA26032; Thu, 1 Feb 1996 16:31:35 -0500 (EST) Date: Thu, 1 Feb 1996 16:31:35 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602012131.QAA26032@ector.cs.purdue.edu> To: 603, fresko, grr Subject: Re: Socket calls to trace Content-Length: 460 > Some calls use value-return parameters, like accept. In that case, it >does not make sense to print some of the arguments, but it makes sense >to print them *after* the call. I print out something like: > >accept(s=7 addr= addrlen=) = 8 {arthur.cs.purdue.edu<128.10.2.1>.20,16} > >that is, I skip the arguments, but type the return arguments. Is that >OK? Or should I print everything out? > >--Nedim > That is the way it should be. --Gustavo ------- From zhuang@cs Compile Error: $> make gcc -c -fPIC socktracelib.cc socktracelib.cc: In function `int bind(int, const struct sockaddr *, int)': socktracelib.cc:219: declaration of C function `int bind(int, const struct sockaddr *, int)' conflicts with /usr/include/sys/socket.h:295: previous declaration `int bind(int, struct sockaddr *, int)' here make: *** [socktracelib.o] Error 1 $> The related source code is: extern "C" int bind(int s, const struct sockaddr *name, int namelen) { fprintf( stderr, "bind(s=%d name=0x%x namelen=%d", s, name, namelen); fprintf(stderr, ") = "); int c = _bind( s, name, namelen); fprintf( stderr, "%d\n", c ); return c; } Same problems for 'sendto' and 'sendmsg'. The other functions are OK. Could you tell what I should do in order to fix the bug? Thanks. -- zhuang ------------------ Define your functions as they are defined in the header files. In the definition of bind use: extern "C" int bind(int s, struct sockaddr *name, int namelen) as it is is socket.h instead of extern "C" int bind(int s, const struct sockaddr *name, int namelen) as it is in the manual pages. Some times the function prototypes in the manual pages are not consistent with the header files. --Gustavo ----From fresko@cs ------------------------------------------------- I am following the "print as it happens" approach you gave in your skeleton for the projcet, and I am getting printouts like: recv(s=6 buf=0xeffff148 len=1024 flags=0) = 90 recvfrom(s=4 buf=0x21968 len=512 flags=0 from=0xeffff950 fromlen=16) = recv(s=6 buf=0xefffee88 len=1024 flags=0) = 81 recv(s=6 buf=0xefffef88 len=1024 flags=0) = 90 404 {wellfleet1.cs.purdue.edu<128.10.2.252>.520,16} recv(s=6 buf=0xefffef08 len=1024 flags=0) = 81 that is, interspersed output. If I change the code, so that it first performs the call and then prints out everything else, this behaviour does not change either. Any ideas what might be happening here? --Nedim -------------------------------------------------------------------- What may be happening is that the function that translates inet-addresses to host names calls other socket funstions. Therefore when you want to display a host name as the return value of "recvfrom", a trace for "recv" appears also on the screen. To avoid this problem "You should disable tracing when tracing" :-). --Gustavo From grr Sun Feb 4 12:43:54 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id MAA08876 for grr; Sun, 4 Feb 1996 12:43:53 -0500 (EST) Date: Sun, 4 Feb 1996 12:43:53 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602041743.MAA08876@ector.cs.purdue.edu> To: grr Subject: 603 Status: RO Content-Length: 278 Date: Fri, 2 Feb 1996 15:39:57 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 78 Sir, How to test our accept(), since this is used on server side? Thanks. huz From grr Mon Feb 5 12:37:19 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id MAA25019; Mon, 5 Feb 1996 12:36:03 -0500 (EST) Date: Mon, 5 Feb 1996 12:36:03 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602051736.MAA25019@ector.cs.purdue.edu> To: psk Subject: Re: socktrace Cc: 603, grr Status: RO Content-Length: 512 > In socktrace is there any specific reason to say > > exec $* > > Why cant we just say > > $* > They are basically the same. However "exec $*" will not return to the shell and "$*" will return to the shell. I choose exec because it seems more efficient. > and also could you give me some help on how to print the total number of calls > at the end... There is a library function called "atexit(proc)" that executes the procedure that you pass as a parameter when the program normally exits. --Gustavo From grr Mon Feb 5 15:26:53 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id PAA11912; Mon, 5 Feb 1996 15:25:45 -0500 (EST) Date: Mon, 5 Feb 1996 15:25:45 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052025.PAA11912@ector.cs.purdue.edu> To: 603 Subject: What to turn in for Project-1 part-1 Cc: grr Status: R Content-Length: 1110 603 Project-1 Part 1 -------------------- The deadline of Project-1 Part-1 is Tuesday Feb 6 before 6:00pm. You can turn in your projects during class or in my office (CS274). You have to turn in a printout of the following: 1. All your source files. 2. The output of running the following commands >socktrace finger russo@leonardo >socktrace ftp ls get bye >socktrace telnet login: password: date exit >socktrace netscape quit 3. Answer to the following questions: a) Why the command "socktrace rusers" crashes? b) Why the command "socktrace rlogin" does not work? c) Why the following does not work? cd / cd /socktrace finger d) What could you do to solve this problem? Some manual pages that may be useful to answer the previous questions are ld(1) and ldd(1). I have updated the handout in http://www.cs.purdue.edu/homes/grr/603/96spring/homepage.html or /.sequoia/u3/603/96spring/project1/part1 --Gustavo From grr Mon Feb 5 16:11:24 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA16349; Mon, 5 Feb 1996 16:10:13 -0500 (EST) Date: Mon, 5 Feb 1996 16:10:13 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052110.QAA16349@ector.cs.purdue.edu> To: 603, fresko, grr Subject: Re: socktrace Status: R Content-Length: 432 > Is there a way to register a procedure to be run on 'loading' a > dynamic module? An initialization routine in which to call 'atexit'? > Or should each function check if the exit function has been registered > or not, and if not, register it. There is a way using "#pragma init (func)" that I have never used. Otherwise I don't see any problem in checking that atexit has been called or not in every socket call. --Gustavo From grr Mon Feb 5 16:12:24 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA16442; Mon, 5 Feb 1996 16:11:40 -0500 (EST) Date: Mon, 5 Feb 1996 16:11:40 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052111.QAA16442@ector.cs.purdue.edu> To: 603, grr Subject: netscape in Xinu machines... Status: R Content-Length: 127 I have been informed that "netscape" is not available in the xinu machines. Use "Mosaic" in your tests instead. --Gustavo From kapadia@ecn.purdue.edu Mon Feb 5 16:27:26 1996 Return-Path: kapadia@ecn.purdue.edu Received: from arthur.cs.purdue.edu (root@arthur.cs.purdue.edu [128.10.2.1]) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) with ESMTP id QAA18029 for ; Mon, 5 Feb 1996 16:27:25 -0500 (EST) Received: from en.ecn.purdue.edu (kapadia@en.ecn.purdue.edu [128.46.128.59]) by arthur.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) with SMTP id QAA21041 for ; Mon, 5 Feb 1996 16:27:22 -0500 (EST) Received: from en.ecn.purdue.edu (kapadia@localhost) by en.ecn.purdue.edu (8.6.12/3.8davy) for delivery to "grr@cs" id QAA21669; Mon, 5 Feb 1996 16:27:17 -0500 Message-Id: <199602052127.QAA21669@en.ecn.purdue.edu> From: Nirav Harish Kapadia Subject: Project... To: grr Date: Mon, 5 Feb 1996 16:27:16 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Status: R Content-Length: 1052 Gustavo, Sorry - I misinterpreted your question. I take it that you want to know why "socktrace" does not intercept the socket calls for rlogin... Thanks, Nirav > > Gustavo, > > > b) Why the command "socktrace rlogin" does not work? > > I'm not sure why you think it won't work. I tried it (on ecn) and it worked. > Here is the output that I got: > > ****************************************************************************** > > /home/yake/gray/kapadia/CS603 % socktrace rlogin jacoby > Password: > Last login: Mon Feb 5 15:53:14 from herman.ecn.purdu > SunOS jacoby.ecn.purdue.edu 5.3 Generic_101318-74 sun4m sparc > > /home/yake/gray/kapadia % date > Mon Feb 5 16:01:40 EST 1996 > /home/yake/gray/kapadia % ls CS603 > Makefile output sock2.c > Old/ sock.c socktrace* > cs603 sock.o socktracelib.so* > /home/yake/gray/kapadia % exit > logout > Connection closed by foreign host. > > ****************************************************************************** From grr Mon Feb 5 16:33:06 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA18393; Mon, 5 Feb 1996 16:31:30 -0500 (EST) Date: Mon, 5 Feb 1996 16:31:30 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052131.QAA18393@ector.cs.purdue.edu> To: 603, grr, kapadia@ecn.purdue.edu Subject: Re: Project... Content-Length: 304 > > b) Why the command "socktrace rlogin" does not work? > > Sorry - I misinterpreted your question. I take it that you want to >know why "socktrace" does not intercept the socket calls for rlogin... > Yes, rlogin works, however the socket calls are not being traced. --Gustavo From grr Mon Feb 5 18:07:41 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id SAA25873; Mon, 5 Feb 1996 18:06:22 -0500 (EST) Date: Mon, 5 Feb 1996 18:06:22 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052306.SAA25873@ector.cs.purdue.edu> To: jwai@ecn.purdue.edu Subject: Re: Project... Cc: 603, grr Status: O Content-Length: 270 > for the printout, is the following enough? > > socket(family=2 type=2 protocol=0) = 6 > > or do we need something like: > > socket(family=AF_INET type=SOCK_STREAM protocol=..... > something like socket(family=AF_INET type=SOCK_STREAM protocol=..... --Gustavo From grr Mon Feb 5 18:31:41 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id SAA27254; Mon, 5 Feb 1996 18:30:25 -0500 (EST) Date: Mon, 5 Feb 1996 18:30:25 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602052330.SAA27254@ector.cs.purdue.edu> To: 603, grr Subject: Question... Content-Length: 171 Eliminate the following question from your writeup... a) Why the command "socktrace rusers" crashes? It seems that the problem is difficult to reproduce. --Gustavo From swang Mon Feb 5 19:53:58 1996 Return-Path: swang@cs.purdue.edu Received: from lisa.cs.purdue.edu (swang@lisa.cs.purdue.edu [128.10.7.22]) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) with ESMTP id TAA01639; Mon, 5 Feb 1996 19:53:33 -0500 (EST) Received: (from swang@localhost) by lisa.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id TAA18160; Mon, 5 Feb 1996 19:53:06 -0500 (EST) From: Sheng-Yih Wang Message-Id: <199602060053.TAA18160@lisa.cs.purdue.edu> Subject: Trace netscape? To: 603 Date: Mon, 5 Feb 1996 19:53:05 -0500 (EST) Cc: swang (Sheng-Yih Wang), grr X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 340 For those who want to trace netscape: To force netscape not to redirect stderr and stdout into a dialog box, edit a file (say 'resource') with the following two lines: *useStderrDialog: False *useStdoutDialog: False Then at the shell, type xrdb -merge resource Now you can trace netscape! Sheng-Yih Wang.