From grr Tue Feb 13 18:34:15 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id SAA16869; Tue, 13 Feb 1996 18:33:33 -0500 (EST) Date: Tue, 13 Feb 1996 18:33:33 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602132333.SAA16869@ector.cs.purdue.edu> To: 603, grr Subject: Handout and iterative httpd... Status: R Content-Length: 473 The complete handout for project1 is available in http://www.cs.purdue.edu/homes/grr/603/96spring/homepage.html I modified httpd to make it iterative (non-forking). Follow the instructions in the handout to install your own copy. I would recommend you to do first the non-forking version of the project and then if you have time do the forking version. There may be a lot of details that can make the forking version difficult to implement. Good luck, --Gustavo > I am trying to get some Solaris documents from the directory you > give us. But I am confused because there are so many files over there > and I couldn't find an index or something. Could you tell me a way > to search though the files? For example, if I want to know more about > process creation ets. Each directory is a different manual. Most of the files are postcript files. Also in each directory there is a file called "files_to_print" that gives you the contents of that manual. --Gustavo From grr Wed Feb 21 16:32:59 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA17774; Wed, 21 Feb 1996 16:32:05 -0500 (EST) Date: Wed, 21 Feb 1996 16:32:05 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602212132.QAA17774@ector.cs.purdue.edu> To: 603, grr Subject: Project 1 deadline Content-Length: 2074 The deadline for project 1 is Tuesday Feb 27 before 5:00pm in my office. You have to turn in a document describing: 1. General design 2. Data structures 3. Calls intercepted 4. Implementation 5. Problems encountered 6. Printout of the sources 7. Output (if any) showing the number of real connections and virtual connections (connections that the user thinks is opening). Since this project has been more complex than we expected, try to do your best and you are not required to turnin a working prototype. However, your document should reflect the time you spent working on this project. Some hints: 1. Setup your own copy of the httpd program as it is described in the handout and trace the calls done by httpd and Mosaic. That will give you an idea of which calls you have to intercept. 2. Since the X-windows library in Mosaic also uses TCP/IP, your library can crash some of the X calls. The solution is to cache only the connections that go to the httpd server, and leave alone the other connections. I recommend you to store the httpd port you are using in an environment variable and only to cache the connections that go to this port. 3. Add a header to every message exchanged between cached clients and servers. This header contains type of message, length, and data. The type could be DATA, CLOSE, etc. When receiving a message block until the message is complete. Use fcntl() to set a socket to block or non block state (fcntl(5) fcntl(2)). Remember to reset the socket to the previousstate 4. httpd uses fwrite to send output through a socket. However, since "fwrite" calls _write instead of write, you need to intercept also fwrite. Unfortunately _fwrite is not defined. Call _fwrite_unlocked(ptr1, size, count, iop) instead of _fwrite when you intercept fwrite (check the sources in /p/src/sun5.3/solaris2.3/os-net/src_ws/usr/src/lib/libc/port/stdio/fwrite.c). 5. Send me e-mail if you find any interesting things that you think we have to share with the group. Good luck. --Gustavo From fresko Tue Feb 20 23:00:38 1996 Return-Path: fresko@cs.purdue.edu Received: from lillee.cs.purdue.edu (fresko@lillee.cs.purdue.edu [128.10.2.68]) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) with ESMTP id XAA10481; Tue, 20 Feb 1996 23:00:37 -0500 (EST) Received: (from fresko@localhost) by lillee.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id XAA11936; Tue, 20 Feb 1996 23:00:09 -0500 (EST) Date: Tue, 20 Feb 1996 23:00:09 -0500 (EST) Message-Id: <199602210400.XAA11936@lillee.cs.purdue.edu> From: Nedim Fresko To: 603 Subject: FYI: Crazy connect from Mosaic! Status: RO Content-Length: 2597 Hi all, Gustavo wants e-mail. I am doing the opening move. :-) FYI: If you wonder why there is usally a double connect to a server in Mosaic, both of which return -1, and yet everything seems to work well... The following is from the Mosaic code that actually does the connect: (file libwww2/HTTCP.c, function HTDoConnect) >>> /* >>> * Make the socket non-blocking, so the connect can be canceled. >>> * This means that when we issue the connect we should NOT >>> * have to wait for the accept on the other end. >>> */ >>> { >>>... [ the ioctl that does that ] ... Now the first connect: >>> /* >>> * Issue the connect. Since the server can't do an instantaneous accept >>> * and we are non-blocking, this will almost certainly return a negative >>> * status. >>> */ >>> status = connect(*s, (struct sockaddr*)&soc_address, sizeof(soc_address)); The error code returned here is most probably EINPROGRESS, meaning the connect has not completed yet. Status == -1. >From the code again: >>> /* >>> * According to the Sun man page for connect: >>> * EINPROGRESS The socket is non-blocking and the con- >>> * nection cannot be completed immediately. >>> * It is possible to select(2) for comple- >>> * tion by selecting the socket for writ- >>> * ing. So now, there is a select loop to test if the socket is ready for writing. The timeout is 1e5 microseconds each time. Now the second connect, when the select returns non-zero: >>> else if (ret > 0) >>> { >>> /* >>> * Extra check here for connection success, if we try to connect >>> * again, and get EISCONN, it means we have a successful >>> * connection. >>> */ >>> status = connect(*s, (struct sockaddr*)&soc_address, >>> sizeof(soc_address)); >>> if ((status < 0)&&(errno == EISCONN)) >>> { >>> status = 0; >>> } >>> break; >>> } Your second connect here returned a -1 also!!! However there is a connection. Now return the socket back to its blocking mode: >>> /* >>> * Make the socket blocking again on good connect >>> */ >>> if (status >= 0) >>>... [ the ioctl that does that ] ... So, there goes the good old model of 1 socket + 1 connect for the client out the window. Probably, errno should be checked in connect when _connect returns a -1, if you consider that case at all. Cheers, --Nedim From grr Wed Feb 21 16:38:23 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA18174; Wed, 21 Feb 1996 16:37:36 -0500 (EST) Date: Wed, 21 Feb 1996 16:37:36 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602212137.QAA18174@ector.cs.purdue.edu> To: 603, grr Subject: Mosaic compiled for SPARC... Content-Length: 190 I compiled Mosaic also for the SPARC architecture. You have now x86: /u/u3/603/96spring/project1/part2/Mosaic-2.6 SPARC: /u/u3/603/96spring/project1/part2/Mosaic-2.6-SPARC --Gustavo From grr Thu Feb 22 16:54:48 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA22005; Thu, 22 Feb 1996 16:53:55 -0500 (EST) Date: Thu, 22 Feb 1996 16:53:55 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602222153.QAA22005@ector.cs.purdue.edu> To: 603, grr Subject: Problems with fwrite (and fprintf)... Content-Length: 738 I have found a solution to the problem of fwrite so you don't need to catch fwrite (and fprintf). The solution is instead of catching write() you have to catch _write(). Inside _write you have to call the write system call directly with syscall(). Example: #include #include #include #include extern "C" int syscall(int number, int arg, ...); extern "C" ssize_t _write(int fildes, const void *buf, size_t nbyte) { syscall( SYS_write, 2, "", 18 ); return syscall( SYS_write, fildes, buf, nbyte ); } main() { fprintf( stderr, "fprintf\n"); char * hello = "Hello my friend\n"; fwrite( hello, strlen( hello ), 1, stderr ); } From grr Thu Feb 22 16:56:44 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id QAA22113; Thu, 22 Feb 1996 16:55:58 -0500 (EST) Date: Thu, 22 Feb 1996 16:55:58 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602222155.QAA22113@ector.cs.purdue.edu> To: 603, grr Subject: Flush a socket... Content-Length: 163 Check the manual page streamio(7). It seems that if you call ioctl( socket, I_FLUSH, FLUSHRW); it will flush the queues of the connection. Try it. --Gustavo From grr Thu Feb 22 17:51:10 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id RAA25380; Thu, 22 Feb 1996 17:50:20 -0500 (EST) Date: Thu, 22 Feb 1996 17:50:20 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602222250.RAA25380@ector.cs.purdue.edu> To: 603, grr Subject: More about write... Status: RO Content-Length: 91 You still need to catch write(). Just make write() to call your own _write(). --Gustavo From grr Fri Feb 23 11:52:09 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id LAA24651; Fri, 23 Feb 1996 11:51:14 -0500 (EST) Date: Fri, 23 Feb 1996 11:51:14 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602231651.LAA24651@ector.cs.purdue.edu> To: 603, grr, hej Subject: Re: X library problem Status: O Content-Length: 688 > 2. Since the X-windows library in Mosaic also uses TCP/IP, your library > can crash some of the X calls. The solution is to cache only the connections > that go to the httpd server, and leave alone the other connections. I recommend > you to store the httpd port you are using in an environment variable > and only to cache the connections that go to this port. > > I think I encountered this problem. But I don't understand > your solution. How to do it? Only cache connections that go to the httpd server port. You can either hardwired the httpd port number in your library or pass the httpd port number to your library using an environment variable. --Gustavo From grr Fri Feb 23 11:54:17 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id LAA24767; Fri, 23 Feb 1996 11:53:31 -0500 (EST) Date: Fri, 23 Feb 1996 11:53:31 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602231653.LAA24767@ector.cs.purdue.edu> To: 603, grr, hej Subject: Re: calls to intercept Content-Length: 551 > > I noticed that the client may call setsockopt() right after > > it called socket(). But if we are to use the old connection (socket), > > the option changed is not reflected in our old socket since the > > new socket is simply closed. > You can get the options set in the original socket using getsockopt() and set the same options in the cached socket using setsockopt(). > I wonder if you can give us a list (maybe not strict) of the calls > we need to intercept for minimum. It is part of the project to identify these calls. --Gustavo From grr Mon Feb 26 11:48:07 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id LAA12378; Mon, 26 Feb 1996 11:47:18 -0500 (EST) Date: Mon, 26 Feb 1996 11:47:18 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602261647.LAA12378@ector.cs.purdue.edu> To: 603, bdd, grr Subject: Re: out-of-band data Status: O Content-Length: 1318 > We chose to implement the "end-of-file" marker using out-of-band data as Dr. > Russo suggested. We have been trying to debug our code for 2 days now, and > we kept not receiving OOB data correctly and getting "Broken pipe" error > messages when sending OOB. > > So we wrote a simple program which all it does is send some regular data, > some OOB data, and another program on the other end to receive it. > > It seems that if the socket has an exceptional condition on it, the OOB data > overwrites the regular buffer data, and 'recv' does not write any data in the > receiving buffer (the one for OOB). Moreover, the results vary, sometimes, > we get the "broken pipe" error on the sender side, sometimes on the receiving > side the OOB data overwrites the regular data, sometimes it doesn't. But in > all the executions, the "right" thing never happened. > > We have read the manual pages, and they don't suggest any solutions or > explanations. Do you have any ideas? Anyone to ask? > I don't have experience with out of band data. Check the implementation of telnet to see how to use it. Telnet is in: /p/src/sun5.3/solaris2.3/os-net/src_ws/usr/src/cmd/cmd-inet/usr.bin/telnet.c Most of the people are either inserting headers in each message or magic numbers to handle control data. --Gustavo From grr Mon Feb 26 11:54:30 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id LAA12775; Mon, 26 Feb 1996 11:53:46 -0500 (EST) Date: Mon, 26 Feb 1996 11:53:46 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602261653.LAA12775@ector.cs.purdue.edu> To: 603, grr, ttd Subject: Re: dynamic linking Content-Length: 512 > We've been trying to intercept fclose() for various reasons. We do that > analogously to intercepting the socket calls - i.e., write a new fclose() which > calls _fclose() . However, when the program is executed, the linker complains > that _fclose() does not exist. Any idea how we fix that? fclose() calls _close() directly. You will need to do the same trick you did with write() and reimplement close() and _close(). close() and _close() have to call syscall( SYS_close, ...) at some point. --Gustavo > Can you tell me what Mosaic do after it received a document? Cause I am sure > that Mosaic have read the document by looking at the received number of bytes. > However, it then called select again and again. My server is blocked in select > also at that point. > Do you have any idea what is going on? The way Mosaic knows the end of a document is when read() returns 0, that means that httpd has already closed the connection. Check your tracings. --Gustavo From grr Tue Feb 27 14:01:04 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id OAA29448; Tue, 27 Feb 1996 14:00:15 -0500 (EST) Date: Tue, 27 Feb 1996 14:00:15 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602271900.OAA29448@ector.cs.purdue.edu> To: 603, grr, kan@ecn.purdue.edu Subject: Re: connect Status: RO Content-Length: 429 > After Mosaic received a document, it will try to do connect again for > getting those images refered in the document. > When Mosaic calls connect for those images, it keeps on calling connect no > matter how I set the returned value and errno. > Do you have any idea what is going on? Check what is the value of errno. The first time errno returns that the connection is now being used cache the connection. --Gustavo From grr Tue Feb 27 14:52:09 1996 Return-Path: grr Received: (from grr@localhost) by ector.cs.purdue.edu (8.7.3/PURDUE_CS-1.4) id OAA03515; Tue, 27 Feb 1996 14:51:22 -0500 (EST) Date: Tue, 27 Feb 1996 14:51:22 -0500 (EST) From: Gustavo Rodriguez-Rivera Message-Id: <199602271951.OAA03515@ector.cs.purdue.edu> To: 603, grr, kan@ecn.purdue.edu Subject: Re: connect Status: R Content-Length: 455 > I have already cached the connection when Mosaic got its document from the > server. When it calls connect again in trying to get the images, I just dup2 > the socket and returned with errno and return value set to 133 & -1 resp. > However, Mosaic keeps on calling connect. It is harmful to call connect for an already connected socket. You do not need to take care of the extra connect calls. Just return what Mosaic expects normally. --Gustavo