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
|
|
|
|
|
|
|
module Remote.Helper.P2P (
|
|
|
|
AuthToken(..),
|
|
|
|
ProtoF(..),
|
|
|
|
runPure,
|
|
|
|
protoDump,
|
|
|
|
auth,
|
2016-11-18 01:56:02 +00:00
|
|
|
checkPresent,
|
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
|
|
|
lockContentWhile,
|
2016-11-18 01:48:59 +00:00
|
|
|
remove,
|
2016-11-17 21:19:04 +00:00
|
|
|
get,
|
|
|
|
put,
|
|
|
|
serve,
|
|
|
|
) where
|
|
|
|
|
|
|
|
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-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)
|
|
|
|
|
|
|
|
-- | 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-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
|
|
|
|
| DATA Len -- followed by bytes
|
2016-11-18 02:06:59 +00:00
|
|
|
| ERROR String
|
2016-11-17 21:19:04 +00:00
|
|
|
deriving (Show)
|
|
|
|
|
|
|
|
-- | Free monad for implementing actions that use the protocol.
|
|
|
|
data ProtoF next
|
|
|
|
= SendMessage Message next
|
2016-11-18 02:10:28 +00:00
|
|
|
| ReceiveMessage (Message -> next)
|
2016-11-17 21:19:04 +00:00
|
|
|
| SendBytes Len L.ByteString next
|
|
|
|
| ReceiveBytes Len (L.ByteString -> next)
|
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-17 21:19:04 +00:00
|
|
|
| KeyFileSize Key (Len -> next)
|
|
|
|
-- ^ Checks size of key file (dne = 0)
|
|
|
|
| ReadKeyFile Key Offset (L.ByteString -> next)
|
2016-11-18 01:27:16 +00:00
|
|
|
| WriteKeyFile Key Offset Len L.ByteString (Bool -> next)
|
|
|
|
-- ^ 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-17 21:19:04 +00:00
|
|
|
| CheckAuthToken UUID AuthToken (Bool -> next)
|
|
|
|
| SetPresent Key UUID next
|
2016-11-18 01:56:02 +00:00
|
|
|
| CheckContentPresent Key (Bool -> next)
|
2016-11-18 01:37:49 +00:00
|
|
|
-- ^ Checks if the whole content of the key is locally present.
|
2016-11-18 01:48:59 +00:00
|
|
|
| RemoveKeyFile Key (Bool -> next)
|
|
|
|
-- ^ If the key file is not present, still succeeds.
|
|
|
|
-- May fail if not enough copies to safely drop, etc.
|
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
|
|
|
| TryLockContent Key (Bool -> Proto ()) next
|
|
|
|
-- ^ 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)
|
|
|
|
|
|
|
|
type Proto = Free ProtoF
|
|
|
|
|
|
|
|
$(makeFree ''ProtoF)
|
|
|
|
|
|
|
|
-- | 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)]
|
|
|
|
runPure (Free (SendMessage m next)) ms = (">", Just m):runPure next ms
|
2016-11-18 02:10:28 +00:00
|
|
|
runPure (Free (ReceiveMessage _)) [] = [("not enough Messages provided", Nothing)]
|
|
|
|
runPure (Free (ReceiveMessage next)) (m:ms) = ("<", Just m):runPure (next m) ms
|
2016-11-17 21:19:04 +00:00
|
|
|
runPure (Free (SendBytes _ _ next)) ms = ("> bytes", Nothing):runPure next ms
|
|
|
|
runPure (Free (ReceiveBytes _ next)) ms = ("< bytes", Nothing):runPure (next L.empty) ms
|
|
|
|
runPure (Free (KeyFileSize _ next)) ms = runPure (next (Len 100)) ms
|
|
|
|
runPure (Free (ReadKeyFile _ _ next)) ms = runPure (next L.empty) ms
|
2016-11-18 01:27:16 +00:00
|
|
|
runPure (Free (WriteKeyFile _ _ _ _ next)) ms = runPure (next True) ms
|
2016-11-17 21:19:04 +00:00
|
|
|
runPure (Free (CheckAuthToken _ _ next)) ms = runPure (next True) ms
|
|
|
|
runPure (Free (SetPresent _ _ next)) ms = runPure next ms
|
2016-11-18 01:56:02 +00:00
|
|
|
runPure (Free (CheckContentPresent _ next)) ms = runPure (next False) ms
|
|
|
|
runPure (Free (RemoveKeyFile _ next)) ms = runPure (next True) ms
|
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
|
|
|
runPure (Free (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
|
|
|
|
sendMessage (AUTH myuuid t)
|
2016-11-18 02:10:28 +00:00
|
|
|
r <- 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-18 02:06:59 +00:00
|
|
|
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
|
|
|
|
sendMessage (CHECKPRESENT key)
|
|
|
|
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
|
|
|
|
sendMessage (LOCKCONTENT key)
|
|
|
|
checkSuccess
|
|
|
|
cleanup True = runproto $ sendMessage UNLOCKCONTENT
|
|
|
|
cleanup False = return ()
|
|
|
|
|
2016-11-18 01:48:59 +00:00
|
|
|
remove :: Key -> Proto Bool
|
|
|
|
remove key = do
|
|
|
|
sendMessage (REMOVE key)
|
|
|
|
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
|
|
|
|
sendMessage (PUT key)
|
2016-11-18 02:10:28 +00:00
|
|
|
r <- 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-18 02:06:59 +00:00
|
|
|
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-18 02:10:28 +00:00
|
|
|
r <- receiveMessage
|
2016-11-17 21:19:04 +00:00
|
|
|
case r of
|
|
|
|
AUTH theiruuid authtoken -> do
|
|
|
|
ok <- checkAuthToken theiruuid authtoken
|
|
|
|
if ok
|
|
|
|
then do
|
|
|
|
sendMessage (AUTH_SUCCESS myuuid)
|
|
|
|
go (Just theiruuid)
|
|
|
|
else do
|
|
|
|
sendMessage AUTH_FAILURE
|
|
|
|
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-18 02:06:59 +00:00
|
|
|
Nothing -> 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
|
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 -> tryLockContent key $ \locked -> do
|
|
|
|
sendSuccess locked
|
|
|
|
when locked $ do
|
|
|
|
r' <- receiveMessage
|
|
|
|
case r' of
|
|
|
|
UNLOCKCONTENT -> return ()
|
|
|
|
_ -> sendMessage (ERROR "expected UNLOCKCONTENT")
|
2016-11-18 02:06:59 +00:00
|
|
|
CHECKPRESENT key -> sendSuccess =<< checkContentPresent key
|
|
|
|
REMOVE key -> sendSuccess =<< removeKeyFile key
|
2016-11-17 21:19:04 +00:00
|
|
|
PUT key -> do
|
2016-11-18 01:56:02 +00:00
|
|
|
have <- checkContentPresent key
|
2016-11-18 01:37:49 +00:00
|
|
|
if have
|
|
|
|
then sendMessage ALREADY_HAVE
|
|
|
|
else do
|
|
|
|
ok <- receiveContent key PUT_FROM
|
|
|
|
when ok $
|
|
|
|
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-18 02:06:59 +00:00
|
|
|
_ -> sendMessage (ERROR "unexpected command")
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
sendContent :: Key -> Offset -> Proto Bool
|
|
|
|
sendContent key offset = do
|
|
|
|
(len, content) <- readKeyFile' key offset
|
|
|
|
sendMessage (DATA len)
|
|
|
|
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
|
|
|
|
Len n <- keyFileSize key
|
|
|
|
let offset = Offset n
|
|
|
|
sendMessage (mkmsg offset)
|
2016-11-18 02:10:28 +00:00
|
|
|
r <- receiveMessage
|
2016-11-18 01:04:35 +00:00
|
|
|
case r of
|
|
|
|
DATA len -> do
|
2016-11-18 01:27:16 +00:00
|
|
|
ok <- writeKeyFile key offset len =<< 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-18 02:06:59 +00:00
|
|
|
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-18 02:10:28 +00:00
|
|
|
ack <- receiveMessage
|
2016-11-18 01:48:59 +00:00
|
|
|
case ack of
|
|
|
|
SUCCESS -> return True
|
|
|
|
FAILURE -> return False
|
|
|
|
_ -> do
|
2016-11-18 02:06:59 +00:00
|
|
|
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 ()
|
|
|
|
sendSuccess True = sendMessage SUCCESS
|
|
|
|
sendSuccess False = sendMessage FAILURE
|
|
|
|
|
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.
|
|
|
|
readKeyFile' :: Key -> Offset -> Proto (Len, L.ByteString)
|
|
|
|
readKeyFile' key (Offset offset) = do
|
|
|
|
(Len totallen) <- keyFileSize key
|
|
|
|
let len = totallen - offset
|
|
|
|
if len <= 0
|
|
|
|
then return (Len 0, L.empty)
|
|
|
|
else do
|
|
|
|
content <- readKeyFile key (Offset offset)
|
|
|
|
return (Len len, content)
|
|
|
|
|
|
|
|
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"]
|
2016-11-18 01:56:02 +00:00
|
|
|
formatMessage (CHECKPRESENT key) = ["CHECKPRESENT", Proto.serialize 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
|
|
|
formatMessage (LOCKCONTENT key) = ["LOCKCONTENT", Proto.serialize key]
|
|
|
|
formatMessage UNLOCKCONTENT = ["UNLOCKCONTENT"]
|
2016-11-18 01:48:59 +00:00
|
|
|
formatMessage (REMOVE key) = ["REMOVE", Proto.serialize key]
|
2016-11-17 21:19:04 +00:00
|
|
|
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]
|
2016-11-18 01:37:49 +00:00
|
|
|
formatMessage ALREADY_HAVE = ["ALREADY-HAVE"]
|
2016-11-17 21:19:04 +00:00
|
|
|
formatMessage SUCCESS = ["SUCCESS"]
|
|
|
|
formatMessage FAILURE = ["FAILURE"]
|
|
|
|
formatMessage (DATA leng) = ["DATA", Proto.serialize leng]
|
2016-11-18 02:06:59 +00:00
|
|
|
formatMessage (ERROR err) = ["ERROR", Proto.serialize err]
|
2016-11-17 21:19:04 +00:00
|
|
|
|
|
|
|
instance Proto.Receivable Message where
|
|
|
|
parseCommand "AUTH" = Proto.parse2 AUTH
|
|
|
|
parseCommand "AUTH-SUCCESS" = Proto.parse1 AUTH_SUCCESS
|
|
|
|
parseCommand "AUTH-FAILURE" = Proto.parse0 AUTH_FAILURE
|
2016-11-18 01:56:02 +00:00
|
|
|
parseCommand "CHECKPRESENT" = Proto.parse1 CHECKPRESENT
|
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
|
|
|
parseCommand "LOCKCONTENT" = Proto.parse1 LOCKCONTENT
|
|
|
|
parseCommand "UNLOCKCONTENT" = Proto.parse0 UNLOCKCONTENT
|
2016-11-18 01:48:59 +00:00
|
|
|
parseCommand "REMOVE" = Proto.parse1 REMOVE
|
2016-11-17 21:19:04 +00:00
|
|
|
parseCommand "GET" = Proto.parse2 GET
|
|
|
|
parseCommand "PUT" = Proto.parse1 PUT
|
|
|
|
parseCommand "PUT-FROM" = Proto.parse1 PUT_FROM
|
2016-11-18 01:37:49 +00:00
|
|
|
parseCommand "ALREADY-HAVE" = Proto.parse0 ALREADY_HAVE
|
2016-11-17 21:19:04 +00:00
|
|
|
parseCommand "SUCCESS" = Proto.parse0 SUCCESS
|
|
|
|
parseCommand "FAILURE" = Proto.parse0 FAILURE
|
|
|
|
parseCommand "DATA" = Proto.parse1 DATA
|
2016-11-18 02:06:59 +00:00
|
|
|
parseCommand "ERROR" = Proto.parse1 ERROR
|
2016-11-17 21:19:04 +00:00
|
|
|
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
|