Jump to content

Quadear

Member
  • Content Count

    13
  • Joined

  • Last visited

About Quadear

  • Rank
    Regular

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks everyone for your imputs, will look at it in details
  2. How can the system determine a "first" in such a decentralized network ? I will obviously be the first to post the transaction on my private rippled, but how does it translate in the "global" ledger ? Timestamp depending on the server's system ? First transaction to reach an UNL server ?
  3. Thanks ! How is that order determined ? first come, first serve I guess ? How can the system determine an order when the system is composed of hundreds of servers, and obviously with different server time for each ?
  4. Hello ! I noticed that in a transaction, I have a IndexInLedger field in addition to the ledgerVersion field. Does that field have any impact on transaction resolution ? from what I understood, I though that all the new transactions were applied atomically on a new ledger. If it indeed has an impact on transaction resolution, is it possible to have any impact on it ? Transaction Example: https://bithomp.com/explorer/A811CD63E2CB0B5FB78EADD7C39BCE76E912F39EF0A6A4490CDC571C7F565742 Thanks,
  5. Thanks for that info, it exeplains a lot indeed. Yeah, my latency is calculated using those timestamps. If they are inexacts ... So I assume there is no way to have exact timestamp for that, because every server doesn't have the same clock.
  6. There is absolutly no problems with that. The issue is indeed in latency. I can't explain that amount of variations. Running a node locally isn't an option here, I don't think just sheer distance (I usually have around 200ms of ping with my server right now, which is more than acceptable) explains the amplitude of the variations. It juste looks like I've missed something on how ledger publication works.
  7. Hi @jlr, Even if my time and the node time aren't synchronised, I expect the gap between them to be linear. The problem is not in the ledger time, the problem is that I seem to get the information of the new ledger in a completly random delay, and that's what bothering me, since I'm requesting the same server, and such, I should have roughly the same delay each ledger. The documentation says: ledger_time Number The time this ledger was closed, in seconds since the Ripple Epoch So what i understood is that when I receive a Ledger Event, it's that the ledger was just clos
  8. Hello there, I'm executing this simple snippet of code in order to watch for ledgers: import WebSocket from 'ws' import * as microtime from 'microtime' const socket = new WebSocket('wss://xrpl.ws') socket.on('open', () => { socket.send(JSON.stringify({ command: 'subscribe', streams: [ 'ledger' ] })) }) socket.on('message', (event) => { const message = JSON.parse(event as string) if (message.ledger_time) { console.log(`============== New Ledger ${message.ledger_index}`) const time = (Number(message.ledger_time) + 946684800) * 1000000 // Get th
  9. I'm already checking if the transaction is in the ledger in the case of a tesSUCCESS, so I can do that with any form or answer, yes. However, it DRASTICALLY reduce my order speed if I need to wait for the next ledger (or the few next depending of the max ledger of my transaction). If there is absolutly no other way, I will try to do so.
  10. hi, I've read this issue, and it seems just great. However, I'm using the JS ripple lib, and the option is not yet available. I've made a PR to add it, but I've been told that the "fail_hard" option is not final yet, so they don't what to merge it juste now. But yeah, this option would be oh so perfect.
  11. hello At this point, it seems I havn't been clear enough. All thoose transactions are sent in the same ledger. So "theorically" i can still move / replace them as seen here: https://xrpl.org/cancel-or-skip-a-transaction.html The problem here is that it seems that replacing a "non persisted yet but still well formed transaction" (I may call that a pending transaction, because it's quite long. We do agree that we are only talking about server-side pendings, so I have already sent the transaction, but the server hasn't integrated it to le ledger), I have the same return message (t
  12. Hello guys, I have a few questions about the mecanics when sending a transaction: I'm trying to send a transaction at a sequence X and the server's answer is a tefPAST_SEQ (my sequence is too low / has already been used), but my transaction is still persisted in the ledger. I don't understand something here. I'm sending transactions by batch, and I have the following pattern: ============Start Ledger N============ Send Transaction Sequence X Send Transaction Sequence X + 1 Send Transaction Sequence X + 2 Send Transaction Sequence X + 3 ============S
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.