convert lockcontent api to http long polling
Websockets would work, but the problem with using them for this is that each lockcontent call is a separate websocket connection. And that's an actual TCP connection. One TCP connection per file dropped would be too expensive. With http long polling, regular http pipelining can be used, so it will reuse a TCP connection. Unfortunately, at least with servant, bi-directional streams with long polling don't result in true bidirectional full duplex communication. Servant processes the whole client body stream before generating the server body stream. I think it's entirely possible to do full bi-directional communication over http, but it would need changes to servant. And, there's no way for the client to tell if the server successfully locked the content, since the server will keep processing the client stream no matter what.: So, added a new api endpoint, keeplocked. lockcontent will lock the key for 10 minutes with retention lock, and then a call to keeplocked will keep it locked for as long as needed. This does mean that there will need to be a Map of locks by key, and I will probably want to add some kind of lock identifier that lockcontent returns.
This commit is contained in:
parent
522700d1c4
commit
82d66ede5e
4 changed files with 228 additions and 84 deletions
|
@ -14,10 +14,13 @@ module Command.P2PHttp where
|
|||
import Command
|
||||
import P2P.Http
|
||||
|
||||
import qualified Network.Wai.Handler.Warp as Warp
|
||||
|
||||
cmd :: Command
|
||||
cmd = command "p2phttp" SectionPlumbing
|
||||
"communicate in P2P protocol over http"
|
||||
paramNothing (withParams seek)
|
||||
|
||||
seek :: CmdParams -> CommandSeek
|
||||
seek _ = liftIO $ P2P.Http.run
|
||||
seek ["server"] = liftIO $ Warp.run 8080 p2pHttpApp
|
||||
seek ["client"] = liftIO testClientLock
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue