2016-11-17 21:19:04 +00:00
|
|
|
{- P2P protocol
|
|
|
|
-
|
|
|
|
- Copyright 2016 Joey Hess <id@joeyh.name>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
{-# LANGUAGE DeriveFunctor, TemplateHaskell, FlexibleContexts, RankNTypes #-}
|
2016-11-17 21:19:04 +00:00
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
module Remote.Helper.P2P where
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
import qualified Utility.SimpleProtocol as Proto
|
|
|
|
import Types.Key
|
|
|
|
import Types.UUID
|
|
|
|
import Utility.Applicative
|
|
|
|
import Utility.PartialPrelude
|
|
|
|
|
|
|
|
import Control.Monad
|
|
|
|
import Control.Monad.Free
|
|
|
|
import Control.Monad.Free.TH
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
import Control.Monad.Catch
|
2016-11-19 20:30:57 +00:00
|
|
|
import System.Exit (ExitCode(..))
|
2016-11-20 16:08:16 +00:00
|
|
|
import System.IO
|
2016-11-17 21:19:04 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
|
|
|
|
|
|
|
newtype AuthToken = AuthToken String
|
|
|
|
deriving (Show)
|
|
|
|
|
|
|
|
newtype Offset = Offset Integer
|
|
|
|
deriving (Show)
|
|
|
|
|
|
|
|
newtype Len = Len Integer
|
|
|
|
deriving (Show)
|
|
|
|
|
2016-11-19 20:30:57 +00:00
|
|
|
-- | Service as used by the connect message is gitremote-helpers(1)
|
|
|
|
data Service = UploadPack | ReceivePack
|
|
|
|
deriving (Show)
|
|
|
|
|
2016-11-17 21:19:04 +00:00
|
|
|
-- | Messages in the protocol. The peer that makes the connection
|
|
|
|
-- always initiates requests, and the other peer makes responses to them.
|
|
|
|
data Message
|
|
|
|
= AUTH UUID AuthToken -- uuid of the peer that is authenticating
|
|
|
|
| AUTH_SUCCESS UUID -- uuid of the remote peer
|
|
|
|
| AUTH_FAILURE
|
2016-11-19 20:30:57 +00:00
|
|
|
| CONNECT Service
|
|
|
|
| CONNECTDONE ExitCode
|
2016-11-18 01:56:02 +00:00
|
|
|
| CHECKPRESENT Key
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
| LOCKCONTENT Key
|
|
|
|
| UNLOCKCONTENT
|
2016-11-18 01:48:59 +00:00
|
|
|
| REMOVE Key
|
2016-11-17 21:19:04 +00:00
|
|
|
| GET Offset Key
|
|
|
|
| PUT Key
|
|
|
|
| PUT_FROM Offset
|
2016-11-18 01:37:49 +00:00
|
|
|
| ALREADY_HAVE
|
2016-11-17 21:19:04 +00:00
|
|
|
| SUCCESS
|
|
|
|
| FAILURE
|
2016-11-19 20:30:57 +00:00
|
|
|
| DATA Len -- followed by bytes of data
|
2016-11-18 02:06:59 +00:00
|
|
|
| ERROR String
|
2016-11-17 21:19:04 +00:00
|
|
|
deriving (Show)
|
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
instance Proto.Sendable Message where
|
|
|
|
formatMessage (AUTH uuid authtoken) = ["AUTH", Proto.serialize uuid, Proto.serialize authtoken]
|
|
|
|
formatMessage (AUTH_SUCCESS uuid) = ["AUTH-SUCCESS", Proto.serialize uuid]
|
|
|
|
formatMessage AUTH_FAILURE = ["AUTH-FAILURE"]
|
|
|
|
formatMessage (CONNECT service) = ["CONNECT", Proto.serialize service]
|
|
|
|
formatMessage (CONNECTDONE exitcode) = ["CONNECTDONE", Proto.serialize exitcode]
|
|
|
|
formatMessage (CHECKPRESENT key) = ["CHECKPRESENT", Proto.serialize key]
|
|
|
|
formatMessage (LOCKCONTENT key) = ["LOCKCONTENT", Proto.serialize key]
|
|
|
|
formatMessage UNLOCKCONTENT = ["UNLOCKCONTENT"]
|
|
|
|
formatMessage (REMOVE key) = ["REMOVE", Proto.serialize key]
|
|
|
|
formatMessage (GET offset key) = ["GET", Proto.serialize offset, Proto.serialize key]
|
|
|
|
formatMessage (PUT key) = ["PUT", Proto.serialize key]
|
|
|
|
formatMessage (PUT_FROM offset) = ["PUT-FROM", Proto.serialize offset]
|
|
|
|
formatMessage ALREADY_HAVE = ["ALREADY-HAVE"]
|
|
|
|
formatMessage SUCCESS = ["SUCCESS"]
|
|
|
|
formatMessage FAILURE = ["FAILURE"]
|
|
|
|
formatMessage (DATA len) = ["DATA", Proto.serialize len]
|
|
|
|
formatMessage (ERROR err) = ["ERROR", Proto.serialize err]
|
|
|
|
|
|
|
|
instance Proto.Receivable Message where
|
|
|
|
parseCommand "AUTH" = Proto.parse2 AUTH
|
|
|
|
parseCommand "AUTH-SUCCESS" = Proto.parse1 AUTH_SUCCESS
|
|
|
|
parseCommand "AUTH-FAILURE" = Proto.parse0 AUTH_FAILURE
|
|
|
|
parseCommand "CONNECT" = Proto.parse1 CONNECT
|
|
|
|
parseCommand "CONNECTDONE" = Proto.parse1 CONNECT
|
|
|
|
parseCommand "CHECKPRESENT" = Proto.parse1 CHECKPRESENT
|
|
|
|
parseCommand "LOCKCONTENT" = Proto.parse1 LOCKCONTENT
|
|
|
|
parseCommand "UNLOCKCONTENT" = Proto.parse0 UNLOCKCONTENT
|
|
|
|
parseCommand "REMOVE" = Proto.parse1 REMOVE
|
|
|
|
parseCommand "GET" = Proto.parse2 GET
|
|
|
|
parseCommand "PUT" = Proto.parse1 PUT
|
|
|
|
parseCommand "PUT-FROM" = Proto.parse1 PUT_FROM
|
|
|
|
parseCommand "ALREADY-HAVE" = Proto.parse0 ALREADY_HAVE
|
|
|
|
parseCommand "SUCCESS" = Proto.parse0 SUCCESS
|
|
|
|
parseCommand "FAILURE" = Proto.parse0 FAILURE
|
|
|
|
parseCommand "DATA" = Proto.parse1 DATA
|
|
|
|
parseCommand "ERROR" = Proto.parse1 ERROR
|
|
|
|
parseCommand _ = Proto.parseFail
|
|
|
|
|
|
|
|
instance Proto.Serializable Offset where
|
|
|
|
serialize (Offset n) = show n
|
|
|
|
deserialize = Offset <$$> readish
|
|
|
|
|
|
|
|
instance Proto.Serializable Len where
|
|
|
|
serialize (Len n) = show n
|
|
|
|
deserialize = Len <$$> readish
|
|
|
|
|
|
|
|
instance Proto.Serializable AuthToken where
|
|
|
|
serialize (AuthToken s) = s
|
|
|
|
deserialize = Just . AuthToken
|
|
|
|
|
|
|
|
instance Proto.Serializable Service where
|
|
|
|
serialize UploadPack = "git-upload-pack"
|
|
|
|
serialize ReceivePack = "git-receive-pack"
|
|
|
|
deserialize "git-upload-pack" = Just UploadPack
|
|
|
|
deserialize "git-receive-pack" = Just ReceivePack
|
|
|
|
deserialize _ = Nothing
|
|
|
|
|
|
|
|
-- | Free monad for the protocol, combining net communication,
|
|
|
|
-- and local actions.
|
|
|
|
data ProtoF c = Net (NetF c) | Local (LocalF c)
|
|
|
|
deriving (Functor)
|
|
|
|
|
|
|
|
type Proto = Free ProtoF
|
|
|
|
|
|
|
|
net :: Net a -> Proto a
|
|
|
|
net = hoistFree Net
|
|
|
|
|
|
|
|
local :: Local a -> Proto a
|
|
|
|
local = hoistFree Local
|
|
|
|
|
|
|
|
data NetF c
|
|
|
|
= SendMessage Message c
|
|
|
|
| ReceiveMessage (Message -> c)
|
|
|
|
| SendBytes Len L.ByteString c
|
|
|
|
| ReceiveBytes Len (L.ByteString -> c)
|
2016-11-20 20:42:18 +00:00
|
|
|
| CheckAuthToken UUID AuthToken (Bool -> c)
|
2016-11-20 16:08:16 +00:00
|
|
|
| Relay RelayHandle
|
|
|
|
(RelayData -> Net (Maybe ExitCode))
|
|
|
|
(ExitCode -> c)
|
|
|
|
-- ^ Waits for data to be written to the RelayHandle, and for messages
|
|
|
|
-- to be received from the peer, and passes the data to the
|
|
|
|
-- callback, continuing until it returns an ExitCode.
|
|
|
|
| RelayService Service
|
|
|
|
(RelayHandle -> RelayData -> Net (Maybe ExitCode))
|
|
|
|
(ExitCode -> c)
|
|
|
|
-- ^ Runs a service, and waits for it to output to stdout,
|
|
|
|
-- and for messages to be received from the peer, and passes
|
|
|
|
-- the data to the callback (which is also passed the service's
|
|
|
|
-- stdin RelayHandle), continuing uniil the service exits.
|
|
|
|
| WriteRelay RelayHandle L.ByteString c
|
|
|
|
-- ^ Write data to a relay's handle, flushing it immediately.
|
|
|
|
deriving (Functor)
|
|
|
|
|
|
|
|
type Net = Free NetF
|
|
|
|
|
|
|
|
data RelayData
|
|
|
|
= RelayData L.ByteString
|
|
|
|
| RelayMessage Message
|
|
|
|
|
|
|
|
newtype RelayHandle = RelayHandle Handle
|
|
|
|
|
|
|
|
data LocalF c
|
2016-11-18 01:27:16 +00:00
|
|
|
-- ^ Lazily reads bytes from peer. Stops once Len are read,
|
|
|
|
-- or if connection is lost, and in either case returns the bytes
|
|
|
|
-- that were read. This allows resuming interrupted transfers.
|
2016-11-20 16:08:16 +00:00
|
|
|
= KeyFileSize Key (Len -> c)
|
2016-11-17 21:19:04 +00:00
|
|
|
-- ^ Checks size of key file (dne = 0)
|
2016-11-20 16:08:16 +00:00
|
|
|
| ReadKeyFile Key Offset (L.ByteString -> c)
|
|
|
|
| WriteKeyFile Key Offset Len L.ByteString (Bool -> c)
|
2016-11-18 01:27:16 +00:00
|
|
|
-- ^ Writes to key file starting at an offset. Returns True
|
|
|
|
-- once the whole content of the key is stored in the key file.
|
|
|
|
--
|
|
|
|
-- Note: The ByteString may not contain the entire remaining content
|
|
|
|
-- of the key. Only once the key file size == Len has the whole
|
|
|
|
-- content been transferred.
|
2016-11-20 16:08:16 +00:00
|
|
|
| SetPresent Key UUID c
|
|
|
|
| CheckContentPresent Key (Bool -> c)
|
2016-11-18 01:37:49 +00:00
|
|
|
-- ^ Checks if the whole content of the key is locally present.
|
2016-11-20 16:08:16 +00:00
|
|
|
| RemoveKeyFile Key (Bool -> c)
|
2016-11-18 01:48:59 +00:00
|
|
|
-- ^ If the key file is not present, still succeeds.
|
|
|
|
-- May fail if not enough copies to safely drop, etc.
|
2016-11-20 16:08:16 +00:00
|
|
|
| TryLockContent Key (Bool -> Proto ()) c
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
-- ^ Try to lock the content of a key, preventing it
|
|
|
|
-- from being deleted, and run the provided protocol action.
|
2016-11-17 21:19:04 +00:00
|
|
|
deriving (Functor)
|
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
type Local = Free LocalF
|
2016-11-17 21:19:04 +00:00
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
-- Generate sendMessage etc functions for all free monad constructors.
|
|
|
|
$(makeFree ''NetF)
|
|
|
|
$(makeFree ''LocalF)
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
-- | Running Proto actions purely, to see what they do.
|
|
|
|
runPure :: Show r => Proto r -> [Message] -> [(String, Maybe Message)]
|
|
|
|
runPure (Pure r) _ = [("result: " ++ show r, Nothing)]
|
2016-11-20 16:08:16 +00:00
|
|
|
runPure (Free (Net n)) ms = runNet n ms
|
|
|
|
runPure (Free (Local n)) ms = runLocal n ms
|
|
|
|
|
|
|
|
runNet :: Show r => NetF (Proto r) -> [Message] -> [(String, Maybe Message)]
|
|
|
|
runNet (SendMessage m next) ms = (">", Just m):runPure next ms
|
|
|
|
runNet (ReceiveMessage _) [] = [("not enough Messages provided", Nothing)]
|
|
|
|
runNet (ReceiveMessage next) (m:ms) = ("<", Just m):runPure (next m) ms
|
|
|
|
runNet (SendBytes _ _ next) ms = ("> bytes", Nothing):runPure next ms
|
|
|
|
runNet (ReceiveBytes _ next) ms = ("< bytes", Nothing):runPure (next L.empty) ms
|
2016-11-20 20:42:18 +00:00
|
|
|
runNet (CheckAuthToken _ _ next) ms = runPure (next True) ms
|
2016-11-20 16:08:16 +00:00
|
|
|
runNet (Relay _ _ next) ms = runPure (next ExitSuccess) ms
|
|
|
|
runNet (RelayService _ _ next) ms = runPure (next ExitSuccess) ms
|
|
|
|
runNet (WriteRelay _ _ next) ms = runPure next ms
|
|
|
|
|
|
|
|
runLocal :: Show r => LocalF (Proto r) -> [Message] -> [(String, Maybe Message)]
|
|
|
|
runLocal (KeyFileSize _ next) ms = runPure (next (Len 100)) ms
|
|
|
|
runLocal (ReadKeyFile _ _ next) ms = runPure (next L.empty) ms
|
|
|
|
runLocal (WriteKeyFile _ _ _ _ next) ms = runPure (next True) ms
|
|
|
|
runLocal (SetPresent _ _ next) ms = runPure next ms
|
|
|
|
runLocal (CheckContentPresent _ next) ms = runPure (next False) ms
|
|
|
|
runLocal (RemoveKeyFile _ next) ms = runPure (next True) ms
|
|
|
|
runLocal (TryLockContent _ p next) ms = runPure (p True >> next) ms
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
protoDump :: [(String, Maybe Message)] -> String
|
|
|
|
protoDump = unlines . map protoDump'
|
|
|
|
|
|
|
|
protoDump' :: (String, Maybe Message) -> String
|
|
|
|
protoDump' (s, Nothing) = s
|
|
|
|
protoDump' (s, Just m) = s ++ " " ++ unwords (Proto.formatMessage m)
|
|
|
|
|
|
|
|
auth :: UUID -> AuthToken -> Proto (Maybe UUID)
|
|
|
|
auth myuuid t = do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (AUTH myuuid t)
|
|
|
|
r <- net receiveMessage
|
2016-11-17 21:19:04 +00:00
|
|
|
case r of
|
|
|
|
AUTH_SUCCESS theiruuid -> return $ Just theiruuid
|
|
|
|
AUTH_FAILURE -> return Nothing
|
|
|
|
_ -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (ERROR "auth failed")
|
2016-11-17 21:19:04 +00:00
|
|
|
return Nothing
|
|
|
|
|
2016-11-18 01:56:02 +00:00
|
|
|
checkPresent :: Key -> Proto Bool
|
|
|
|
checkPresent key = do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (CHECKPRESENT key)
|
2016-11-18 01:56:02 +00:00
|
|
|
checkSuccess
|
|
|
|
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
{- Locks content to prevent it from being dropped, while running an action.
|
|
|
|
-
|
|
|
|
- Note that this only guarantees that the content is locked as long as the
|
|
|
|
- connection to the peer remains up. If the connection is unexpectededly
|
|
|
|
- dropped, the peer will then unlock the content.
|
|
|
|
-}
|
|
|
|
lockContentWhile
|
|
|
|
:: MonadMask m
|
|
|
|
=> (forall r. Proto r -> m r)
|
|
|
|
-> Key
|
|
|
|
-> (Bool -> m ())
|
|
|
|
-> m ()
|
|
|
|
lockContentWhile runproto key a = bracket setup cleanup a
|
|
|
|
where
|
|
|
|
setup = runproto $ do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (LOCKCONTENT key)
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
checkSuccess
|
2016-11-20 16:08:16 +00:00
|
|
|
cleanup True = runproto $ net $ sendMessage UNLOCKCONTENT
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
cleanup False = return ()
|
|
|
|
|
2016-11-18 01:48:59 +00:00
|
|
|
remove :: Key -> Proto Bool
|
|
|
|
remove key = do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (REMOVE key)
|
2016-11-18 01:48:59 +00:00
|
|
|
checkSuccess
|
|
|
|
|
2016-11-17 21:19:04 +00:00
|
|
|
get :: Key -> Proto Bool
|
2016-11-18 01:04:35 +00:00
|
|
|
get key = receiveContent key (`GET` key)
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
put :: Key -> Proto Bool
|
|
|
|
put key = do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (PUT key)
|
|
|
|
r <- net receiveMessage
|
2016-11-17 21:19:04 +00:00
|
|
|
case r of
|
|
|
|
PUT_FROM offset -> sendContent key offset
|
2016-11-18 01:37:49 +00:00
|
|
|
ALREADY_HAVE -> return True
|
2016-11-17 21:19:04 +00:00
|
|
|
_ -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (ERROR "expected PUT_FROM")
|
2016-11-17 21:19:04 +00:00
|
|
|
return False
|
|
|
|
|
|
|
|
-- | Serve the protocol.
|
|
|
|
--
|
|
|
|
-- Note that if the client sends an unexpected message, the server will
|
|
|
|
-- respond with PTOTO_ERROR, and always continues processing messages.
|
|
|
|
-- Since the protocol is not versioned, this is necessary to handle
|
|
|
|
-- protocol changes robustly, since the client can detect when it's
|
|
|
|
-- talking to a server that does not support some new feature, and fall
|
|
|
|
-- back.
|
|
|
|
--
|
2016-11-18 02:06:59 +00:00
|
|
|
-- When the client sends ERROR to the server, the server gives up,
|
2016-11-17 21:19:04 +00:00
|
|
|
-- since it's not clear what state the client is is, and so not possible to
|
|
|
|
-- recover.
|
|
|
|
serve :: UUID -> Proto ()
|
|
|
|
serve myuuid = go Nothing
|
|
|
|
where
|
|
|
|
go autheduuid = do
|
2016-11-20 16:08:16 +00:00
|
|
|
r <- net receiveMessage
|
2016-11-17 21:19:04 +00:00
|
|
|
case r of
|
|
|
|
AUTH theiruuid authtoken -> do
|
2016-11-20 20:42:18 +00:00
|
|
|
ok <- net $ checkAuthToken theiruuid authtoken
|
2016-11-17 21:19:04 +00:00
|
|
|
if ok
|
|
|
|
then do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (AUTH_SUCCESS myuuid)
|
2016-11-17 21:19:04 +00:00
|
|
|
go (Just theiruuid)
|
|
|
|
else do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage AUTH_FAILURE
|
2016-11-17 21:19:04 +00:00
|
|
|
go autheduuid
|
2016-11-18 02:06:59 +00:00
|
|
|
ERROR _ -> return ()
|
2016-11-17 21:19:04 +00:00
|
|
|
_ -> do
|
|
|
|
case autheduuid of
|
|
|
|
Just theiruuid -> authed theiruuid r
|
2016-11-20 16:08:16 +00:00
|
|
|
Nothing -> net $ sendMessage (ERROR "must AUTH first")
|
2016-11-17 21:19:04 +00:00
|
|
|
go autheduuid
|
|
|
|
|
2016-11-18 01:04:35 +00:00
|
|
|
authed _theiruuid r = case r of
|
2016-11-20 16:08:16 +00:00
|
|
|
LOCKCONTENT key -> local $ tryLockContent key $ \locked -> do
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
sendSuccess locked
|
|
|
|
when locked $ do
|
2016-11-20 16:08:16 +00:00
|
|
|
r' <- net receiveMessage
|
Add content locking to P2P protocol
Is content locking needed in the P2P protocol? Based on re-reading
bugs/concurrent_drop--from_presence_checking_failures.mdwn,
I think so: Peers can form cycles, and multiple peers can all be trying
to drop the same content.
So, added content locking to the protocol, with some difficulty.
The implementation is fine as far as it goes, but note the warning
comment for lockContentWhile -- if the connection to the peer is dropped
unexpectedly, the peer will then unlock the content, and yet the local
side will still think it's locked.
To be honest I'm not sure if Remote.Git's lockKey for ssh remotes
doesn't have the same problem. It checks that the
"ssh remote git-annex-shell lockcontent"
process has not exited, but if the connection closes afer that check,
the lockcontent command will unlock it, and yet the local side will
still think it's locked.
Probably this needs to be fixed by eg, making lockcontent catch any
execptions due to the connection closing, and in that case, wait a
significantly long time before dropping the lock.
This commit was sponsored by Anthony DeRobertis on Patreon.
2016-11-18 05:32:24 +00:00
|
|
|
case r' of
|
|
|
|
UNLOCKCONTENT -> return ()
|
2016-11-20 16:08:16 +00:00
|
|
|
_ -> net $ sendMessage (ERROR "expected UNLOCKCONTENT")
|
|
|
|
CHECKPRESENT key -> sendSuccess =<< local (checkContentPresent key)
|
|
|
|
REMOVE key -> sendSuccess =<< local (removeKeyFile key)
|
2016-11-17 21:19:04 +00:00
|
|
|
PUT key -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
have <- local $ checkContentPresent key
|
2016-11-18 01:37:49 +00:00
|
|
|
if have
|
2016-11-20 16:08:16 +00:00
|
|
|
then net $ sendMessage ALREADY_HAVE
|
2016-11-18 01:37:49 +00:00
|
|
|
else do
|
|
|
|
ok <- receiveContent key PUT_FROM
|
|
|
|
when ok $
|
2016-11-20 16:08:16 +00:00
|
|
|
local $ setPresent key myuuid
|
2016-11-18 00:54:14 +00:00
|
|
|
-- setPresent not called because the peer may have
|
|
|
|
-- requested the data but not permanatly stored it.
|
2016-11-18 01:04:35 +00:00
|
|
|
GET offset key -> void $ sendContent key offset
|
2016-11-19 20:30:57 +00:00
|
|
|
CONNECT service -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
exitcode <- net $ relayService service relayCallback
|
|
|
|
net $ sendMessage (CONNECTDONE exitcode)
|
|
|
|
_ -> net $ sendMessage (ERROR "unexpected command")
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
sendContent :: Key -> Offset -> Proto Bool
|
|
|
|
sendContent key offset = do
|
2016-11-19 20:30:57 +00:00
|
|
|
(len, content) <- readKeyFileLen key offset
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (DATA len)
|
|
|
|
net $ sendBytes len content
|
2016-11-18 01:48:59 +00:00
|
|
|
checkSuccess
|
2016-11-17 21:19:04 +00:00
|
|
|
|
2016-11-18 01:04:35 +00:00
|
|
|
receiveContent :: Key -> (Offset -> Message) -> Proto Bool
|
|
|
|
receiveContent key mkmsg = do
|
2016-11-20 16:08:16 +00:00
|
|
|
Len n <- local $ keyFileSize key
|
2016-11-18 01:04:35 +00:00
|
|
|
let offset = Offset n
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (mkmsg offset)
|
|
|
|
r <- net receiveMessage
|
2016-11-18 01:04:35 +00:00
|
|
|
case r of
|
|
|
|
DATA len -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
ok <- local . writeKeyFile key offset len
|
|
|
|
=<< net (receiveBytes len)
|
2016-11-18 02:06:59 +00:00
|
|
|
sendSuccess ok
|
2016-11-18 01:04:35 +00:00
|
|
|
return ok
|
|
|
|
_ -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (ERROR "expected DATA")
|
2016-11-18 01:04:35 +00:00
|
|
|
return False
|
2016-11-17 21:19:04 +00:00
|
|
|
|
2016-11-18 01:48:59 +00:00
|
|
|
checkSuccess :: Proto Bool
|
|
|
|
checkSuccess = do
|
2016-11-20 16:08:16 +00:00
|
|
|
ack <- net receiveMessage
|
2016-11-18 01:48:59 +00:00
|
|
|
case ack of
|
|
|
|
SUCCESS -> return True
|
|
|
|
FAILURE -> return False
|
|
|
|
_ -> do
|
2016-11-20 16:08:16 +00:00
|
|
|
net $ sendMessage (ERROR "expected SUCCESS or FAILURE")
|
2016-11-18 01:48:59 +00:00
|
|
|
return False
|
|
|
|
|
2016-11-18 02:06:59 +00:00
|
|
|
sendSuccess :: Bool -> Proto ()
|
2016-11-20 16:08:16 +00:00
|
|
|
sendSuccess True = net $ sendMessage SUCCESS
|
|
|
|
sendSuccess False = net $ sendMessage FAILURE
|
2016-11-18 02:06:59 +00:00
|
|
|
|
2016-11-17 21:19:04 +00:00
|
|
|
-- Reads key file from an offset. The Len should correspond to
|
|
|
|
-- the length of the ByteString, but to avoid buffering the content
|
|
|
|
-- in memory, is gotten using keyFileSize.
|
2016-11-19 20:30:57 +00:00
|
|
|
readKeyFileLen :: Key -> Offset -> Proto (Len, L.ByteString)
|
|
|
|
readKeyFileLen key (Offset offset) = do
|
2016-11-20 16:08:16 +00:00
|
|
|
(Len totallen) <- local $ keyFileSize key
|
2016-11-17 21:19:04 +00:00
|
|
|
let len = totallen - offset
|
|
|
|
if len <= 0
|
|
|
|
then return (Len 0, L.empty)
|
|
|
|
else do
|
2016-11-20 16:08:16 +00:00
|
|
|
content <- local $ readKeyFile key (Offset offset)
|
2016-11-17 21:19:04 +00:00
|
|
|
return (Len len, content)
|
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
connect :: Service -> Handle -> Handle -> Proto ExitCode
|
|
|
|
connect service hin hout = do
|
|
|
|
net $ sendMessage (CONNECT service)
|
|
|
|
net $ relay (RelayHandle hin) (relayCallback (RelayHandle hout))
|
2016-11-19 20:30:57 +00:00
|
|
|
|
2016-11-20 16:08:16 +00:00
|
|
|
relayCallback :: RelayHandle -> RelayData -> Net (Maybe ExitCode)
|
|
|
|
relayCallback hout (RelayMessage (DATA len)) = do
|
|
|
|
writeRelay hout =<< receiveBytes len
|
|
|
|
return Nothing
|
|
|
|
relayCallback _ (RelayMessage (CONNECTDONE exitcode)) =
|
|
|
|
return (Just exitcode)
|
|
|
|
relayCallback _ (RelayMessage _) = do
|
|
|
|
sendMessage (ERROR "expected DATA or CONNECTDONE")
|
|
|
|
return (Just (ExitFailure 1))
|
|
|
|
relayCallback _ (RelayData b) = do
|
|
|
|
let len = Len $ fromIntegral $ L.length b
|
|
|
|
sendMessage (DATA len)
|
|
|
|
sendBytes len b
|
|
|
|
return Nothing
|