dg@lakart.UUCP (David Goodenough) (06/19/89)
Yet another question spawned by a problem with my new UUCP system talking to HDB - this is a hex dump of a file received: Sector 0000 of B:D-E0-9D7.USR 0000: 67 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 g............... 0010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040: 46 72 6f 6d 20 64 61 76-65 67 20 20 53 61 74 20 From daveg Sat 0050: 4a 75 6e 20 31 37 20 32-32 3a 33 34 3a 35 35 20 Jun 17 22:34:55 0060: 31 39 38 39 20 72 65 6d-6f 74 65 20 66 72 6f 6d 1989 remote from 0070: 20 75 73 6f 75 72 63 65-0a 52 65 63 65 69 76 65 usource.Receive The rest is not important - the question I have is: What gives with the extra junk packet sent before the file transmission really got under way?? (i.e. a 'g' and 63 nulls) - does HDB add some extra crud that isn't documented? and if so can someone please post some form of information about it. This is from a Xenix SCO system running a version of HDB - standard BSD UUCP (both V4.2 and 4.3) don't do this. Or is this just a bug in HDB? Enquiring minds want to know?????? Also I want to know how I can tell the difference between junk and real binary data when I'm receiving grafix pixel information - I can think of several ways of discarding the errant packet, but all of them run a risk of discarding valid data when a binary file transfer is in progress - and I plan to use this to dial in to remote access sites and UUCP out compressed files, so I need binary transmission to work right. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+