Return-Path: william@bourbon.usc.edu Delivery-Date: Sat Sep 6 14:07:18 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m86L7Ic9025445 for ; Sat, 6 Sep 2008 14:07:18 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id m86L5qAb027844 for ; Sat, 6 Sep 2008 14:05:52 -0700 Message-Id: <200809062105.m86L5qAb027844@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: CS551 warmup1 - TCP stream abstraction Date: Sat, 06 Sep 2008 14:05:52 -0700 From: Bill Cheng Someone wrote: > I have a question with TCP stream abstraction. > I found that although sender sends data byte by byte continuously, > receiver will get whole piece of data instead of fragment. > ie. send 10 byte, send() function run 10 times. However, recv() only run 1 > times and get all 10bytes data. The spec requires you to read/recv one byte at a time! So, you will need to call recv() 10 times in this case. > So I add sleep(1) between each 1 byte send(). > It turns out that recv() will run 10 times and each time get 1 byte. Except for sleeping for one whole second, you got the right idea. > Is this the way that system is designed? If I want to know more about this, > could you tell me some reference or keywords? Almost! You need to call select() before you call recv(). You should make select() return if there is data ready to be read in the socket file descriptor. Also, you should use a timeout value of 100 millisecond in the last argument of select(). This way, if there is data in the socket, select() will return right away. > By the way, during my experiment, I got "broken pipe" msg once. (I don't > know why receiver closed the socket automatically). Only 1 byte sent to > receiver successfully. > I am confused why it sometimes works, sometimes not. > Is it cause by OS or other user? Broken pipe means that the other side of the connect has closed the socket. This can certainly happen since the client and the server are different processes and you cannot control the timing between them. You should handle SIGPIPE and probably not treat it as an error. -- Bill Cheng // bill.cheng@usc.edu