diff options
Diffstat (limited to 'tupkg/README.txt')
| -rw-r--r-- | tupkg/README.txt | 99 |
1 files changed, 0 insertions, 99 deletions
diff --git a/tupkg/README.txt b/tupkg/README.txt deleted file mode 100644 index 47facc46..00000000 --- a/tupkg/README.txt +++ /dev/null @@ -1,99 +0,0 @@ -TU Packaging Tools (tupkg) --------------------------- -- client side (python for proof of concept, later re-write to C?) - The main purpose of this tool is to upload the compiled - pkg.tar.gz to the server. It can (should?) do some verification - on the package prior to uploading to the server. It will have - a config file to store run-time information such as username - (email), password, and server name. - -- server side (python for proof of concept, later re-write to C?) - The server side will handle incoming connections from its client - side counterpart. The server should bind to port 80 (maybe a - vhost such as tupkg.archlinux.org?) so that firewalls won't be - an issue. The server verifies the client authentication data, - and then accepts the package(s). If port 80 is not available, - perhaps 443, or are there other 'standard' ports that usually - do not get filtered? - - I think the server should be multithreaded to handle simultaneous - uploads rather than queue up requests. The download should be - stored in a temp directory based on the username to prevent - directory, filename clashes. - - Once the package(s) is uploaded, the server can either kick off - a gensync, or we can write a separate script to call gensync once - or twice a day. My preference would be a separate script to call - gensync (like the *NIX philosophy of one tool per task). - -- protocol (c: => client, s: => server) - Whenever the client/server exchange a message, it is always - preceeded by two-bytes representing the following message's - length. For example, when the client connects, it will send: - - 0x0028username=bfinch@example.net&password=B0b - - 0x0028 is the 40 byte strlen of the message in two-bytes. The - client and server always read two-bytes from the socket, and - then know how much data is coming and can read that amount of - bytes from the socket. - - ==> authentication - c: username=emailaddy&password=mypassword - s: result=PASS|FAIL - - NOTE: We can add encryption easily enough with the python - version using the socket.ssl method. - - ==> uploading package data - if PASS: - - c: numpkgs=2&name1=p1.pkg.tar.gz&size1=123&md5sum1=abcd\ - name2=p2.pkg.tar.gz&size2=3&md5sum2=def1 - s: numpkgs=2&name1=p1.pkg.tar.gz&size1=119&\ - name2=p2.pkg.tar.gz&size2=0 (*) - - (*) NOTE: The server will reply back to the client how many - packages it has already received and its local file size. - This way, the client can resume an upload. In the example - above, the server still needs the last four (123-119) bytes - for the first package, and that it has no part of the - second package. The client would then begin sending the - last four bytes from the first package (p1.pkg.tar.gz) and - then follow it with the full second package (p2.pkg.tar.gz). - The data would be sent as a continuous chunk of data. The - server will then need to track which bytes belong to which - package. - - else FAIL: - c: -spits out error message on stderr to user- - - - ==> after upload completes - The server should verify the integrity of the uploaded packages - by doing an md5sum on each and sending the info back to the client - for comparison. After sending the message, the server waits for - the 'ack' message from the client and then closes the connection. - - s: np=2&m1=PASS&m2=FAIL - c: ack - - The client replies with the 'ack' and then closes its connection - to the server. It then reports the PASS/FAIL status of each - package's upload attempt. - - NOTE: If the upload fails (client connection dies), the server - keeps any data it has received in order to support resuming an - upload. However, if the client uploads all data, and the server - successully reads all data and the final MD5 fails, the server - deletes the failed package. - - -Terms/definitions: -====================== -TU - No change (trusted by the community, if anyone asks what trust - means) -TUR - renamed to Arch User-community Repo (AUR) (so we can use -u for - versions) -Incoming - renamed to "Unsupported" - |