Protocol

From Catchcopy
Jump to: navigation, search

Protocol

Target

This protocol define the communication between an explorer (or all other application which do copy) and software of file copy.

Choice of the mode of communication

The choice have been done, it's use QLocalServer (The application of copy) and QLocalSocket (the file explorer). Under windows then it's done with named pipe and under unix an unix socket.

That's allow isolate the language (server in c++ and client in Qt) and the architecture (server 32Bits to portable version and client in 64Bits like the explorer.exe of Windows 64Bits)

It's allow too only the local connexion and detect the application disconnection or of the client (with crash too example).

About the performance, a Pentium 3 at 500MHz can transfer of this mode 1GB/s, to copy list very ofter < at 32KB (the transfer is done in 30µs -> 0.00003s, that's greatly lower then copy time). Better performance is useless here.

About security, that's do the process is kept into the user space.

  • For windows: The name of the named pipe is: "advanced-copier-[user]", where [user] is the user name in hexa + little endian. Example, for the user named: "user", the encoded string form WCHAR is "7500730065007200", then it do: advanced-copier-7500730065007200
  • For unix: The path of the unix socket is: "/tmp/advanced-copier-[uid]", where [uid] is the id of the current user, example: /tmp/advanced-copier-1000

Decomposition and recomposition

All order/reply need be cute as packet of 32KB max. To check correct size to the receiver and header of int unsigned of 32Bits is included, and it contain size of all the order/reply. The receiver need remove this header and group all frame in unique frame.

Encoding used

The used encoding is the l'unicode (utf16), where each char is encoded into 16Bits in big endian. All modern OS use it.

Format of the composed frame

The order can not be more than 64MB. Format of the order's data (after frame have been composed and header of size removed):
0000DC79000000060000000200610000000400610062000000060061006200630000000800610062006300640000000a006100620063006400650000000c006100620063006400650066

0000DC79 here it's the id of the order, done by the client, it's a 32Bits unsigned int.
In decomposing that's do:
  • 00000006 List size (32Bits unsigned int)
  • 00000002 (string size in bytes, 32Bits unsigned int) 0061 -> a
  • 00000004 (string size in bytes, 32Bits unsigned int) 00610062 -> ab
  • 00000006 (string size in bytes, 32Bits unsigned int) 006100620063 -> abc
  • 00000008 (string size in bytes, 32Bits unsigned int) 0061006200630064 -> abcd
  • 0000000a (string size in bytes, 32Bits unsigned int) 00610062006300640065 -> abcde
  • 0000000c (string size in bytes, 32Bits unsigned int) 006100620063006400650066 -> abcdef
The protocol is done to asynchronous work.

The reply

For the reply, we return id of order finished, the return code, and the return info if needed:
0000DC7900000138800000001000000180075006e006b006e006f00770020006f0072006400650072

In decomposing it do:
0000DC79 the order id, see at top (32Bits unsigned int)
000001388 return code, it decimal it do 5000 -> unknow order (32Bits unsigned int)
  • 00000001 List size (32Bits unsigned ints)
  • 00000018 (string size in bytes, 32Bits unsigned int) 0075006e006b006e006f00770020006f0072006400650072 -> unknow order
The reply can not be more than 64MB. Then the minimal reply size is: sizeof(32Bits unsigned int)+sizeof(32Bits unsigned int)+sizeof(32Bits unsigned int) -> 12 bytes.

Send multiple frame

To send multiple frame then distinct order, the frames recomposed are:
Send copy A to do with the id DC79:
0000DC79000000060000000200610000000400610062000000060061006200630000000800610062006300640000000a006100620063006400650000000c006100620063006400650066

End of previous packet and new packet. The 2 frames wouldn't be concatenated.
Send copy B to do with the id DC7A (the number is new because need be unique to identify the reply linked with it):
0000DC7A000000060000000200610000000400610062000000060061006200630000000800610062006300640000000a006100620063006400650000000c006100620063006400650066

Order send in the protocol

Here the order allowed, the [] need be replace by theres values.
The texts can be varied with server, the return code no.
The return code is returned like unsigned int 32Bits and not as string.
All the unknow order is ignored by the application:

Send protocol used (obligation at the connexion):
  • protocol
  • 0002

Reply:
    • 1000
    • protocol supported
    • 5000
    • incorrect argument list size
    • 5001
    • incorrect argument
    • 5003
    • protocol not supported

Dection of protocol extension:
  • protocol extension
  • [nom de l'extension]
  • [version de l'extension (facultatif)]

Reply:
    • 1001
    • protocol extension supported
    • 1002
    • protocol extension not supported
    • 5000
    • incorrect argument list size
    • 5001
    • incorrect argument

Client identification (if you want):
  • client
  • [client name]

Reply:
    • 1003
    • client registered
    • 5000
    • incorrect argument list size
    • 5001
    • incorrect argument

Ask server name:
  • server
  • name?

Réponses possible:
    • 1004
    • [Server name]
    • 5000
    • incorrect argument list size
    • 5001
    • incorrect argument

Send copy/move list
cp or mv, for copy or move, and cp-? or mv-? for the software ask the destination -> then list without destination
each arguement need do 1 to 65535 char
The list (cp/mv included) need containt 3 to 65535 entry
The dir separation should be \ under windows, and / under unix
  • cp
  • [source1]
  • [source2]
  • [destination]

Reply:
    • 1005
    • finished
    • 1006
    • finished with error(s)
    • 1007
    • canceled
    • 5000
    • incorrect argument list size
    • 5001
    • incorrect argument

IIf the order is unknow:
  • 5002
  • unknow order