Return-Path: william@bourbon.usc.edu Delivery-Date: Sun Nov 16 11:00:33 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.4 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 mAGJ0XTr024936 for ; Sun, 16 Nov 2008 11:00:33 -0800 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id mAGIunIc012527 for ; Sun, 16 Nov 2008 10:56:49 -0800 Message-Id: <200811161856.mAGIunIc012527@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: Misunderstanding TCP stream? Date: Sun, 16 Nov 2008 10:56:49 -0800 From: Bill Cheng Someone wrote: > How would we read in a our sha1 hash hex encoded string and convert it into > a 20 byte buffer? Well, you can write a function that convert 2 characters to one byte: unsigned char HexstringOfTwoToOneByte(char *in) /* assuming that everything in in[] are lowercase */ { unsigned char hi_nibble=0; unsigned char lo_nibble=0; switch (in[0]) { case '0': hi_nibble = 0; break; case '1': hi_nibble = 1; break; ... case 'e': hi_nibble = 14; break; case 'f': hi_nibble = 15; break; } switch (in[1]) { case '0': lo_nibble = 0; break; case '1': lo_nibble = 1; break; ... case 'e': lo_nibble = 14; break; case 'f': lo_nibble = 15; break; } return (hi_nibble*16)+lo_nibble; } Then call this function 20 times with the input buffer shifted by 2 characters each time and the output buffer shifted by 1 byte each time. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- From: Bill Cheng [mailto:william@bourbon.usc.edu] Sent: Saturday, November 15, 2008 7:35 AM To: cs551@merlot.usc.edu Subject: Re: Misunderstanding TCP stream? Someone wrote: > Due to the buffer size constraints, I first send the message common header > and metadata. I then iteratively read in 'chunks' of the file data, and send > each 'chunk' individually. The common header of course tells the client how > much data to expect, including the file data. > > When I attempt this though, for some reason, the client reads in the correct > number of bytes, but the file data bytes are incorrect. And then a few > seconds later the client seg faults. Am I misunderstanding / misusing the > TCP stream? I thought this should work? Sounds like you are doing it correctly. This is also what we did for warmup #1 (except that instead of reading and writing one block at a time, we were reading and writing one byte at a time). If your warmup #1 is working properly, you can change it to do it the same way you are doing and you should see that it works. So, my guess is that the bug is somewhere else. -- Bill Cheng // bill.cheng@usc.edu