Copyright Xerox Corporation 1979, 1980Inter-Office MemorandumToCommunicaton ProtocolsDateNovember 12, 1980FromDavid BoggsLocationPalo AltoSubjectCopyDisk ProtocolOrganizationParc(Version 3)XEROX Filed on: CopyDisk.bravo, -.pressThe CopyDisk protocol is a means for making a bit-for-bit copy of a disk through the network. Thefirst version of the protocol was designed and implemented in the summer of 1976. The protocolwas redesigned during the summer of 1977 to handle Trident disks, and extended during the springof 1980 to speak to IFSs and (eventually) tape servers.OverviewThere are two parties to a disk copy: a server which listens for connection requests at a well-knownsocket, and a user which initiates a connection to a server and thereafter controls the server bycommands. The direction of data transfer over the connection is determined by the user and isorthogonal to who is user and who is server.Commands and responses take the form of blocks with type, length, and data fields. The format ofthe data field is determined by the block type and sometimes the disk type. A Byte Stream Protocolconnection is used since blocks can exceed the maximum size of a Pup, but a form of ReliablePacket Protocol which preserved the block boundries would be more suitable.This protocol may be used to copy any type of disk. The data within some commands are intendedfor consumption by the concerned disk driver modules and are transported without interpretation bythe protocol. CopyDisk programs need not implement all disk types; the protocol includes amechanism for negotiating the type of disk to copy.Two guiding principles were used in the design of this protocol: 1) the server should be passive,responding to commands from the user, but never initiating action on its own, and 2) the usershould be responsible for checking the reasonableness of operations while the server just does whatit is told, protecting itself only against self-inflicted damage. The similarity of the CopyDiskprotocol to the File Transfer Protocol is intentional. In this design I am experimenting with somevariations which are likely to show up in the next major revision to FTP.The ProtocolThe details of command formats are given in following sections. This section describes the order ofcommands and their general semantics. Copying a disk involves the following steps:Connection establishment The user opens a BSP connection with the server and sends a [Version]command with a protocol version number and herald text as data. The server sends a [Version]response with its version and herald text. If the versions are not the same, the user should close theconnection.Unit negotiation The user sends a [SendDiskParams] command with a unit name as data. The serverattempts to parse the unit name, and if successful sends a [HereAreDiskParams] response with thedisk parameters as data. If the server doesn't understand the unit name, or is unable to referenceЪНnОpТXП&Н]Оg~qТiНІОcrН]pТXН-єrН7BpНІО]ШrН]p Н-єrН7BpНІОYrН]pН-єrН7BpН]ОW│ НЭОSЛspНЇОMЪП&НыОH6Т│П-Т┌П5НыОF╡Т═Т║ПRНыОE-Т▐П`НыОC╘ТП7НыО@еtНыО=ЮpТ░Т▒upП6НыО<\Тю upП"ТаП-НыО:ьТ╣П.ТІП0НыО9TТП,НыО6oТ░П4upupТ▒upНыО4КТ┌ПLТ┐НыО3gТ╧П#Т╨П9НыО1ЦТПKНыО.ЧТ┬П8Т┴П'НыО-zТ└Т┘ПPНыО+ЖТыП%ТзП6НыО*rТП3НыО'█Т╞ПCТ╟НыО& ТбП/ТцП.НыО$┘Т∙ПMТ√НыО#ТЮТАПDНыО!}Т°Т²ПOНыОЬТПIНыОtНыО/pТ┼ Т▀ПYНыО╚ТПSНыОфuТ╟pП<Т╠ НыОBТ╡ТЁПFНыОЎТ├ПCТ┤П$НыО: НыОUuТ┌pП6Т┐НыОяТёП:ТєП&НыОMТ÷ПLТ═ Эр>/d 9CopyDisk Protocol2the unit (because, for example, it is not ready), it sends a [No] response.This step may be repeated several times as the user pokes around trying to find the right disk. Theserver should remember the last disk for which parameters were sent. Subsequent transfercommands apply to that disk.Data Transfer If the server responded with disk parameters, the user may now send a transfercommand with transfer parameters as data. The transfer parameters are a message from the user'sdisk driver to the server's disk driver describing the sectors to be transferred. The server shouldrespond [Yes] or [No]. If the response was [Yes], disk pages begin flowing; user-to-server if thetransfer command was [StoreDisk], or server-to-user if the command was [RetrieveDisk]. After thesource transmits the last page, it should send an [EndOfTransfer] command.The data transfer step may be repeated several times and the direction in which data flows may notbe the same each time (for example it may be [StoreDisk] the first time and [RetrieveDisk] thesecond time). These commands always refer to the disk last decribed by a [HereAreDiskParams]response from the server. The format and ordering of disk pages within a transfer is private to thedisk drivers involved.Error Reporting The user sends a [SendErrors] command to the server who responds with[HereAreErrors] with errors as data. The format is private to the disk drivers involved.Command and Response DescriptionsCommands and responses are sent in blocks with a type, length, and (possibly empty) data field.Implementors are cautioned to flush the byte stream in situations where no other data follows ablock that must be received by the other party to prevent a deadlock.[Version]

 Identifies the sender's protocol version.   is the protocol version, and  is arbitrarytext.  The CopyDisk user should issue this command immediately upon opening a connection, andthe server should respond with a [Version] reply.  It is the user's responsibility to check forcompatible protocol versions.  I recommend that the herald text be displayed.[Login]    Sent by the user to authenticate access to the server.  The four strings are in Bcpl string format, andbegin on word boundaries (so there will be a byte of garbage following a string with an evennumber of characters).  A word of zeros is a legal Bcpl string with zero characters and should beused where no string is available.  The server should respond with [Yes] or [No]; inclusion of theproper [No] subcode is strongly recommended since the user program can then automatically promptits client to correct the problem.[SendDiskParamsW] [SendDiskParamsR] Sent by the user, this command requests the server to supply disk parameters for the unitcorresponding to .  SendDiskParamsW means that the user intends to write on the specifiedunit.  This is necessary for servers such as IFSs which must verify that the user has write access tothe file, or can create it if it doesn't exist.  The server should respond with [HereAreDiskParams] or[No].[HereAreDiskParams] Sent by the server in response to [SendDiskParams] to describe the disk mentioned in the previous[SendDiskParams] command.  Sent by the user just before a [StoreDisk] command.  This isnecessary for servers such as IFSs which must store the parameters in the file so that they can bereturned in response to a [SendDiskParams] command during retrieval.  Servers that copy to a realdisk whose shape can be determined may ignore these.[StoreDisk] Sent by the user to initiate a data transfer from user to server.  The server should respond [Yes] or[No].  The  are private format and describe the pages to be transferred in theНЇОfЯpТНGОНыОbПKНыО_9Т┼П@Т▀П$НыО]╣ТЭПDТЩНыО\1ТНыОYLuТкpП"ТлП-НыОWхТ°ПHТ²НыОVDТўТ╞ПDНыОTюТЁТЄПUНыОS<Т⌡П3Т°П.НыОQ╦ТПJНыОNсТ█П^Т▌НыОMOТҐП"ТЎП<НыОKкТ╟Т╠П@НыОJGТ▒П5Т▓П/НыОHцТНыОEчuТ
pПAТНыОDZТПYНыОAutП!НыО>░pТ╟ПXТ╠НыО=ТЇПGТ╦НыО;┬ТПEНыО8ёНыО7Т╣П1ТІП3НыО5⌡Т Т⌡ПJНыО4ТАП1ТБП.НыО2⌠ТПMНыО/ўП1НыО.*Т├Т┤П`НыО,іТиПHТйНыО+"Т╔П^ТіНыО)·ТёП.ТєП4НыО(Т│ПKТ┌НыО&√ТП"НыО#╠НыО"-НыО ╘ТЖП5ТВП$НыО%Т░П6Т▒П+НыО║Т≈ПUТ≤НыОТ█ПfНыО≥НыОЄТП%НыО0Т≈Т≤ПLНыО╛ТНПTТОНыО(Т║Т╒ПUНыОєТ≤П9Т≥П(НыО ТП4НыО
;П!НыОЇТ▒Т▓П^НыО
3Т≈Т≤ПCЪЇ	Л?/^ZCopyDisk Protocol3jargon of the concerned disk drivers.[RetrieveDisk] Sent by the user to initiate a data transfer from server to user.  The server should respond [Yes] or[No].  The  are private format and describe the pages to be transferred in thejargon of the concerned disk drivers.[HereIsDiskPage] Transfers a page in either direction.  The format of  is private to the disk drivers participatingin the current transfer.[EndOfTransfer]  (no data)Sent by the source of disk pages to mark the end of a transfer.  If the destination disk driverencounters an [EndOfTransfer] before the last page (which it knows from the transfer parameters),then the transfer was aborted.[SendErrors]  (no data)Sent by the user, it commands the server to report any errors that occurred during the last datatransfer.  The data field of this command is empty.  The server should respond with[HereAreErrors].  [SendErrors] is legal after a data transfer command and up to the next[SendDiskParams] command.[HereAreErrors]  Sent by the server in response to [SendErrors].  The format of  is private to the disk type ofthe last data transfer command.[Yes]  A positive response.   may supply additional machine-readable information of possibleinterest to the receiver, or it may be zero; however the meaning of [Yes] in terms of the protocol isdetermined by the context and not the .   is arbitrary text.[No]  A negative response.   may supply additional machine-readable information of possibleinterest to the receiver, or it may be zero; however the meaning of [No] in terms of the protocol isdetermined by the context and not the .   is arbitrary text which I recommend bedisplayed when received.[Comment] Used to supply commentary, indicate non-fatal errors, etc.     is arbitrary text which shouldbe displayed for the human user.  This command is a no-op with respect to protocol interactionsand may occur in any context.An ExampleIn the following example, the user wishes to overwrite the server's DP0, and then check that the bitsarrived safely by reading it back (presumably comparing the incoming copy against the original). User: [Version] <3> "CopyDisk User 3.00, April 20, 1980"Server: [Version] <3> "CopyDisk Server 3.00, April 20, 1980User checks compatibility of protocol and possibly closes connectionUser: [SendDiskParamsW] "DP0"Server: [HereAreDiskParams]   or [No] <1> "Unit not ready"If the server sent parameters, the user checks their consistancyUser: [HereAreDiskParams] User: [StoreDisk] Server: [Yes] <0> "Ready to overwrite DP0"  or [No] <2> "Overwriting DP0 is not allowed"If the server responded [Yes] then...User: [HereIsDiskPage] ЪНЇОfЯpТНGОНыОbП%НыО_9П$НыО]╣Т▒Т▓П^НыО\1Т≈Т≤ПCНыОZґТП%НыОWхНыОVDТ┌Т┐ПNНыОTюТНыОQшНыОPWТбП_НыОNсТ═П$Т║П=НыОMOТНыОJjНыОHФТЁ
ТЄПUНыОGbТ-П)Т.П*НыОEчТП'Т
П1НыОDZТНыОAuНыО?ЯТ┬П^Т┴НыО>mТНыО;┬НыО:ТФПRТГНыО8─Т▌П@Т▐П%НыО6ЭТПJНыО4НыО2⌠ТчПRТъНыО1Т▓Т⌠ПKНыО/▀Т╛П%ТґП9НыО.ТНыО+"НыО)·Т▐П#Т░ПBНыО(Т╙П&Т╚П9НыО&√ТНыО#╠t	НыО лpТ└П,Т┘П9НыОHТ╣ПQТІТНоОcupП2uНоОъpП4НоО[uПDНоОвpНоОSupП&НоОоupНоОKuП@НоОгpП&НоОCupП"НоО©upП#НоО
;upП*НоОЇuП%НоО
3pЪ,Ї	Л>/^0CopyDisk Protocol4. . .User: [HereIsDiskPage] User: [EndOfTransfer]Copy is complete now.  If the user wishes to check it then...User: [HereAreDiskParams] User: [RetrieveDisk] Server: [Yes] <0> "Sending DP0"Server: [HereIsDiskPage] . . .Server: [HereIsDiskPage] Server: [EndOfTransfer]Finally the user tells the server to report any errorsUser: [SendErrors]Server: [HereAreErrors] Public Block FormatsAll command blocks have the same header to permit handling by agents without knowledge of theircontents:word 0:length in words including this oneword 1:block typeThe format of the [SendDiskParams] command is:words 0-1:standard headerremainder:Bcpl-format unit name stringThe unit name should conform to the unit name conventions of the server.  This specificationrecommends a unit name syntax for each disk type specified.The format of the [HereAreDiskParams] response is part public and part private.  The disk type is ina fixed place so that, for example, a TFS disk driver can detect receipt of BFS parameters andrefuse the copy.words 0-1:standard headerword 2:registered disk type (see below)remainder:private formatAn IFS or tape server should respond with a disk type of 0 when asked for disk parameters by auser who intends to write; users should interpret this wildcard disk type as compatible with all realdisk types.Block types [Yes], [No], and [Version] have a common format:word 0-1:standard headerword 2:subcoderemainder:Bcpl-format stringThe subcode in [Yes] and [No] commands may contain a machine-readable argument to facilitatemechanical handling of exceptional conditions.  Zero should be used in the absense of any code.The subcode in a [Version] command is the protocol version.Alto Diablo (BFS) Private FormatsThese formats are used by disk drivers which copy Diablo disks formated as Alto file systems.  Irecommend that unit 'n' be referred to as "DPn".  Sectors are sent in increasing real disk addressorder during a data transfer.The format of the disk parameters in a [HereAreDiskParams] response is:НЇОfЯpТНGОНёОbНоО` upНоО_upНоО]▓uП=НёО\upП%НеОZfupП%НеОXБupНеОW^upН≥ОUзНеОTVupНеОRрupНоОQ+uП6НоОOїpНоОN#upНыОK>tНыОHYpТ┬П:Т┴П%НыОFуНоОCПТ─Н═ТНоОBlТ─Н═ТНыО?┤П.НоО<╒Т─	Н═ТНоО;	Н═НыО89ТйП-ТкП/НыО6╣ТП;НыО3пТ─П.Т│П6НыО2LТ╪П@ТҐНыО0хТНоО-ДТ─	Н═ТНоО,_Т─Н═	ТНоО*ш	Н═
НыО'ВТ║П0Т╒П.НыО&sТ∙ПWТ√
НыО$НТ
НыО"
П<НоО%Т─Н═ТНоО║Т─Н═НоО	Н═ТНыО8Т╟П&Т╠П6НыОЄТўП/Т╞П0НыО0ТП;НыОKtП!НыОfpТ╗Т╘ПOНыОБТ║Т╒ПHНыО
^ТНыО
yПG8Ї
2?/]ы&CopyDisk Protocol5words 0-1:standard headerword 2:12B (registered disk type)word 3:# of cylindersword 4:# of headsword 5:# of sectorsword 6:# of disksThe format of the transfer parameters in [RetrieveDisk] and [StoreDisk] commands is:words 0-1:standard headerwords 2:first real disk addresswords 3:last real disk addressThe format of a [HereIsDiskPage] command is:words 0-1:standard headerwords 2-3:header recordwords 4-11:label recordwords 12-267:data recordFree pages (those with -1 in the serial and version number fields of the label record) may omit thedata record, reducing the size of IFS files and speeding network transfers.  I recommend that pageswhich are marked incorrigable (even if CopyDisk can read them without errors) and pages whichgive unrecoverable read errors be transmitted as free pages.The format of the errors in a [HereAreErrors] response is:words 0-1:standard headerword 2:number of hard errorsword 3:number of soft errorsAlto Trident (TFS) Private FormatsThese formats are used by disk drivers that copy Trident disks formated as Alto file systems (thisincludes Interim File Systems).  Trident disks with different formatting (such as Juniper disks)should be treated separately.  I recommend that unit 'n' be referred to as "TPn".  Sectors are sent inincreasing real disk address order during a data transfer.The format of the disk parameters in a [HereAreDiskParams] response is:words 0-1:standard headerword 2:2 (registered disk type)word 3:# of cylindersword 4:# of headsword 5:# of sectorsThe format of the transfer parameters in [RetrieveDisk] and [StoreDisk] commands is:words 0-1:standard headerwords 2-3:first real disk addresswords 4-5:last real disk addressReal page 0 should not be copied, so as not to overwrite the destination disk's bad page list.CopyDisk should verify that the destination disk has a well-formed bad page list, and if not, anempty one should be created.The format of a [HereIsDiskPage] command is:words 0-1:standard headerwords 2-3:real disk addressЪНЇОfЯpТНGОНоОbТ─	Н═ТНоО` Т─Н═rpТНоО_Т─Н═ТНоО]▓Т─Н═ТНоО\Т─Н═Т
НоОZ┼Т─Н═ТНыОW╔ПTНоОTюТ─	Н═ТНоОS<Т─Н═ТНоОQ╦Т─Н═ТНыОNсП,НоОKНТ─	Н═ТНоОJjТ─	Н═ТНоОHФТ─
Н═ТНоОGbТ─Н═ТНыОD}Т⌠ПHТ■НыОBЫТ▐Т░ПEНыОAuТ╙П8Т╚П%НыО?ЯТП<НыО=П:НоО:'Т─	Н═ТНоО8ёТ─Н═ТНоО7Т─Н═ТНыО4:tП"НыО1UpТ╔ТіПDНыО/яТяПYТрНыО.MТ┌ПGТ┐НыО,иТП:НыО)ДПGНоО'Т─	Н═ТНоО%|Т─Н═ТНоО#ЬТ─Н═ТНоО"sТ─Н═ТНоО ОТ─Н═Т
НыОПTНоО&Т─	Н═ТНоО╒Т─	Н═ТНоОТ─	Н═ТНыО9ТпП.ТяП0НыО╣ТІПXТЇНыО1ТНыОLП,НоОgТ─	Н═ТНоО
ЦТ─	Н═ТзЇ
°?/]oiCopyDisk Protocol6words 4-13:label recordwords 14-1037:data recordFree pages (those with -1 in the serial and version number fields of the label record) may omit thedata record, reducing the size of IFS files and speeding network transfers.  I recommend that pageswhich are marked incorrigable (even if CopyDisk can read them without errors) and pages whichgive unrecoverable read errors be transmitted as free pages.The format of the errors in a [HereAreErrors] response is:words 0-1:standard headerword 2:number of hard errorsword 3:number of soft errorsOpcode AssignmentsAll numbers are octal.The well-known socket for a CopyDisk server is 25.The following block types are assigned:1[Version]2[SendDiskParamsR]3[HereAreDiskParams]4[StoreDisk]5[RetrieveDisk]6[HereIsDiskPage]7[EndOfTransfer]10[SendErrors]11[HereAreErrors]12[No]13[Yes]14[Comment]15[Login]16[SendDiskParamsW]The following [No] codes are assigned:1Unit not ready2Unit write protected (hardware write-protect)3Overwrite not allowed (software write-protect)4Unknown command20Illegal user name21Illegal or incorrect user password23Illegal connect name24Illegal or incorrect connect passwordThe following disk types are assigned:12Diablo disk with standard BFS formatting2Trident disk with standard TFS formatting3Trident disk with Juniper formatting0Wildcard (see above)Revision HistoryJune 21, 1977Draft release for comments.НЇОfЯpТНGОНоОbТ─
Н═ТНоО` Т─
Н═ТНыО]╣Т⌠ПHТ■НыО\1Т▐Т░ПEНыОZґТ╙П8Т╚П%НыОY)ТП<НыОVDП:НоОS_Т─	Н═ТНоОQшТ─Н═ТНоОPWТ─Н═ТНыОMrtНыОJ█pНыОG╗П2НыОDдП'НоОAъНёНоО@[НёНоО>вНёНоО=SНё
НоО;оНё
НоО:KНёНоО8фНёНоО7BНёНоО5ЎНёНоО4:НёНоО2ІНёНоО12НёНоО/ўНёНоО.*НёНыО+EП&НоО(`Нё
НоО&эНёП-НоО%XНёП.НоО#тНёНоО"PНёНоО лНёП"НоОHНёНоОдНёП%НыОъП&НоОЗНёП(НоОvНёП)НоОРНёП$НоОnНёНыО┴tНыО
╔pНыО nЇы>/\2CopyDisk Protocol7July 22, 1977Changed TFS protocol: transfer parameters now contains real disk addresses and disk pages nowinclude the header record.December 18, 1977Changed BFS protocol: transfer parameters now contains real disk addresses and disk pages nowinclude the header record.April 20, 1980Incompatible protocol extentions to work with IFSs and (eventually) tape servers.  BFS diskparameters now contain number of heads and sectors.November 12, 1980Changed BFS protocol: BFS disk parameters now contain number of disks.ЪНЇОfЯpТНGОНыОbНыО` ТЁП@ТЄНыО_ТНыО\1НыОZґТЁП@ТЄНыОY)ТНЇОUЩ
НЇОTyТФП-ТГП.НЇОRУТП3НЇОOйНЇОNFПFЇMЪ>/L
TIMESROMAN

TIMESROMAN
TIMESROMANLOGO
TIMESROMAN

TIMESROMAN
г
іпз!≈'И,Є/ЪЪj/20√9ж╘ЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪcopydisk.bravoBoggsNovember 12, 1980  3:35 PM