jl777
Realtime events types
Using the new websocket API I'm getting messages with the following method property:
"request" "reserved" "connect" "connected" "tradestatus" "postprice"
Are you able to give a bit more information on what possible methods/messages I should expect and what they mean?
My assumptions are:
request Alice sent out a buy/sell
reserved Bob has matched Alice's buy/sell
connect Alice tries to start the trade with Bob
connected Alice has successfully initiated the trade
tradestatus The status of a trade
postprice A post in the orderbook
I'm sure these aren't totally correct but they seem to be roughly how they work. Can you explain in any more detail what they mean and let me know if there are other message types I haven't encountered yet?
alice makes a "request" bob potentially responds with "reserved" alice potentially responds with "connect" bob potentially responds with "connected"
after the above (unless something goes wrong) the swap is started
tradestatus is about an ongoing swap
currently all public messages are sent so you can get details on the current overall global network state. by looking inside for your node's pubkey you can filter the global stream to be just about what affects your node.
it is a global stream with everything from everybody, if you dont filter it, it will have a lot of stuff that you wont necessarily care about.
there should also be a "failed" message in case a swap fails and that is only a local event there should also be event messages for the specific tx of a specific swap, you can check the requestid/quoteid to know which swap it is.
I would suggest to make a filter to see if your pubkey is in the "pubkey", "srchash" or "desthash" field, or that requestid/quoteid is about a swap you care about.
That will get rid of 99% of the datastream and make it much easier to correlate with what is happening
I would suggest to make a filter to see if your pubkey is in the "pubkey", "srchash" or "desthash" field, or that requestid/quoteid is about a swap you care about.
Thanks, was already implementing the tradeid, missed the pubkey fields.
Btw, I was filtering based on tradeid, not requestid/quoteid. Is this safe? You mentioned in a previous discussion that tradeid is only local to the daemon and requestid/quoteid are network wide.
However if I changed my query to instead check requestid/quoteid the results where the same. And I could see tradeid from remote network requests.
it isnt dangerous to use tradeid, but you could miss the requestid/quoteid you are interested in. you didnt get any extra events using requestid/quoteid filter?
if so that is a bug. I know, I will add a "method":"update" to the swapstatus update events. give me a minute
OK, its there. "update" method for any change to swap in progress and it will have an "update" field with the name of the tx that is being updated. you might get more than one for a specific tx
it is only a local event so you can just check for update method and process the requestid/quoteid
you didnt get any extra events using requestid/quoteid filter? if so that is a bug.
Nope, looks like there's a bug. I just did a new trade and tested both and I actually got less results querying via requestid/quoteid:
(messages is an array of every single message received over the WebSocket)
> messages.filter(msg => msg.tradeid === 1914410009)
(9) [Object, Object, Object, Object, Object, Object, Object, Object, Object]
> messages.filter(msg => msg.requestid === 4283696586 && msg.quoteid === 3987110328)
(2) [Object, Object]
I can dump the full message output here if it's helpful, don't wanna spam if it's not. But you can see from the other issue (#645), lots of the messages have tradeid but are missing requestid/quoteid. These are the ones we are missing, we don't seem to get any extra ones that have requestid/quoteid but don't have tradeid.
https://komodo-platform.slack.com/files/U02QSHX81/F9KQX8459/-.sh
here is a typical entry:
{"name":"bobdeposit","coin":"REVS","tx":"010000000147dc15dba328cc389435124254e2bc90cf513325a8971e2cd59daa68b00c8909000000006a47304402205c41ab2a8ef5bb40494ab6235bf09fbf52b984a0e2e82098b23bdcc20dbe834f022029ea45d2f5f7fe972da6277b99a2de81e01e1840db1f1650c76202910d5ec3810121034464397e3e64a9a1e05bf41c2bcf53a3e34972a7c25b6f89b890ea66c90f16b9ffffffff02b3b63a000000000017a914eaaecbc8dd0e95bcbdaf042de788d54572e56a1d879e9a0300000000001976a914ac6637f97ab212cd65c1f0cb8c6d23c61731bf5188ac4809a05a","txid":"2285827f0c3dcf9ed5da3cd4909bac927aace0f0cac852ee23ad2f31df18a467","Bdeposit":"ba8ADAFrHEHnrSpaCf25k1NvpMLq1wjrGX","expiration":1520437576,"iambob":0,"bobcoin":"REVS","alicecoin":"KMD","lock":0,"amount":0.03847859,"Apayment":"bUT5EtVRovuVzwxw5aZ6AB3TeBpuQUumW4","redeem":"63044809a05ab17582012088a91465c1826e7bc1d633485d529aba60d8e52a72e3d4882102a316fbf1abf3b763f5bfc5a63c5e3035aa0da7c0d8c31786e7d0b1ef65d40a6eac6782012088a914daad2c6919166f4fcc4ed221602ad9cdaca0ae14882103f965882d27292befb100fdfdada1c8087079653be4c106bab105ffbfa802c9b1ac68","method":"update","update":"bobdeposit"}}
aha! I see the problem, the requestid/quoteid are missing. I will add them
https://komodo-platform.slack.com/files/U02QSHX81/F9KR8L90T/-.sh
has a version of a swap without garbage at the end
aha! I see the problem, the requestid/quoteid are missing. I will add them
loool, let me know when it's fixed and I'll test again.
Working, thanks!
> messages.filter(msg => msg.tradeid === 2575306931)
(8) [Object, Object, Object, Object, Object, Object, Object, Object]
> messages.filter(msg => msg.requestid === 488692801 && msg.quoteid === 2737634208)
(7) [Object, Object, Object, Object, Object, Object, Object]
> messages.filter(msg => (msg.tradeid === 2575306931) || (msg.requestid === 488692801 && msg.quoteid === 2737634208))
(12) [Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object]
So to clarify, the possibly update values are: myfee, bobdeposit, alicepayment, bobpayment. After bobpayment the trade is complete. Is that correct?
If any of these steps were to fail, will we get a fail message? Like:
{
"method":"update",
"update":"failed",
...
}
for alice after alicespend or aliceclaim, the swap is complete, assuming alicepayment went out
for bob it is a bit more complicated, in the case the 3 primary tx were sent, then bob is done when he gets 2 back, usually bobspend and bobrefund, but bobspend could be bobclaim. not sure the best way to do this, 90%+ of the time it follows:
bobdeposit, alicepayment, bobpayment then alicespend, bobspend, bobrefund
probably good to get the mainstream case working smooth before worrying about the exceptions.
also a "failed" of course means something went wrong and the swap is stopped. not 100% sure I got all possible paths to failure, but I tried.