Re: Doubt about Websocket / Rest Messages sequence in ILP transaction

Digging into the code at  https://github.com/interledgerjs/ilp/blob/master/src/lib/receiver.js,  it is using first the expires_at date from the request to create a preimage crypto-condition, then, when the message is received, it recreates the preimages crypto-condition from the packet.data.expires_at.  If it doesn't match it nevers sends a fulfillment.

  function createRequest (params) {
    ...
    const paymentRequest = { ...
      expires_at: params.expiresAt || moment().add(defaultRequestTimeout, 'seconds').toISOString() <---
    }
    const conditionPreimage = generateConditionPreimage(hmacKey, paymentRequest)
    ...
  }
  function autoFulfillConditions (transfer) {
    ...
    const paymentRequest = { ...
      expires_at: packet.data && packet.data.expires_at                                            <---
    }

    const conditionPreimage = generateConditionPreimage(hmacKey, paymentRequest)

    if (transfer.executionCondition !== toConditionUri(conditionPreimage)) {
      ...
      return 'condition-mismatch'
    }
  }
No sure why the memo from five-bells-ledger keeps the same expires_date while the java implementation doesn't (whithout the "patch"). I didn't have time to look at this issue today.

Regards,

Enrique





________________________________
De: Evan Schwartz [evan@ripple.com]
Enviado: jueves, 17 de noviembre de 2016 14:13
Para: Enrique Arizon Benito
CC: Adrian Hope-Bailie; Interledger Community Group
Asunto: Re: Doubt about Websocket / Rest Messages sequence in ILP transaction

I'm not sure I can tell from that what the exact issue is.

I want to clarify one thing though: there are two types of expiries and the ledger should only care about one of them. Transfers have an expires_at field and the Interledger Payment Request (data goes inside the transfer memo as part of the ILP packet) does too. The ledger should only look at the expiry of the transfer. It must treat everything in the memo field as opaque.

In general, the way that expiries are being handled in the code right now is somewhat naive, so it's not terribly surprising that it caused an issue.

On Thu, Nov 17, 2016 at 10:38 AM, Enrique Arizon Benito <enrique.arizon.benito@everis.com<mailto:enrique.arizon.benito@everis.com>> wrote:
Hi,

I just pushed to https://github.com/everis-innolab/java-ilp-master master branch.

A brief doc (https://github.com/everis-innolab/java-ilp-master/blob/master/java-ilp-ledger-api/dev_docs/setup_testing_environement.txt<https://github.com/everis-innolab/java-ilp-master/blob/master/java-ilp-ledger-api/dev_docs/setup_testing_environement.txt>) explains a possible setup environment for testing.

Regards!

Enrique
________________________________
De: Adrian Hope-Bailie [adrian@hopebailie.com<mailto:adrian@hopebailie.com>]
Enviado: miércoles, 16 de noviembre de 2016 20:44
Para: Enrique Arizon Benito
CC: Evan Schwartz; Interledger Community Group
Asunto: Re: Doubt about Websocket / Rest Messages sequence in ILP transaction

Hey Enrique,

Where is this code executing?
I think the reason it works is because you're changing the expiry in the header which might not be a good thing.

I'll try and look tomorrow at the Java code and give you some thoughts!

Adrian

On 16 November 2016 at 20:40, Enrique Arizon Benito <enrique.arizon.benito@everis.com<mailto:enrique.arizon.benito@everis.com>> wrote:

Hi Evan,

thanks a lot for the info.

Definetly it put me in the right direction. Finally the timeout looks to be originated some issues with the "expire_at" data.

I just juggled around with the code to make a first transfer work between the java ledger and the five-bells-ledger, but to say the true I'm not still really confident about my code. For example I just switched:

// DTTM_expires: expires_at from the PUT /transfer/:id request
// ilp_ph_expires: expires_at from the ilp_header
if (! DTTM_expires.equals(ilp_ph_expires)){
      ilp_ph_expires = DTTM_expires;
}

for

if (! DTTM_expires.equals(ilp_ph_expires)){
      DTTM_expires = ilp_ph_expires;
}

and that looks to work!, but don't ask me why :(


________________________________
De: Evan Schwartz [evan@ripple.com<mailto:evan@ripple.com>]
Enviado: martes, 15 de noviembre de 2016 18:23
Para: Enrique Arizon Benito
CC: Interledger Community Group
Asunto: Re: Doubt about Websocket / Rest Messages sequence in ILP transaction

Hi Enrique,

Try running the ILP module script and the connector with DEBUG=*.

The things I would look for in the ILP module log output would be some error message when the client tries to submit the fulfillment or an error in the connector logs saying something about why it might not be forwarding the payment.

The general message sequence is:

  1.  Sending client submits transfer to sending ledger
  2.  Sending ledger sends notifications of transfer being prepared to sender and connector
  3.  Connector submits transfer to destination ledger
  4.  Destination ledger sends notifications to connector and receiver
  5.  Receiver submits fulfillment to destination ledger
  6.  Destination ledger sends notifications to receiver and connector (with the fulfillment attached)
  7.  Connector submits fulfillment to sending ledger
  8.  Sending ledger executes transfer and sends notifications to connector and sender

Let me know if that helps. We can definitely talk about this on the CG call tomorrow if you have more questions.

Best,
Evan



On Tue, Nov 15, 2016 at 4:16 PM, Enrique Arizon Benito <enrique.arizon.benito@everis.com<mailto:enrique.arizon.benito@everis.com>> wrote:
I created a test lab demo with 2 five-bells-ledgers, a java ledger and the ilp-connector. Now I try to tests transaction between the different ledgers using the Combined-Example at https://github.com/interledgerjs/ilp. It works fine using 2 five-bells-ledger (as expected). When I try to make a trans. from java ledger to five-bells-ledgers it fails with a timeout (transaction expired). I can see the ws messages sending the notification about a new prepared transaction.

For some reason that I ignore the fulfillment is never "triggered", due (I suppose) to a missing web socket message or PUT request, but even using tcpdump to compare the network traces I can NOT find the problem.

 The real problem is that I'm not 100% sure about the expected message sequence between the "wallet" (ilp Combined-Example), the ledger/s and the ILP so I'm not sure how/where to start debugging the problem.

 Is there any documentation detailing this sequence of Websocket / Rest messages for a full transaction?


Regards,

Enrique Arizon Benito
Software Architect,
Tel: +34 976 482 080, ext 117064<tel:%2B34%20976%20482%20080%2C%20ext%20117064>

http://www.everis.com
















________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.



--
Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http://UrlBlockedError.aspx><http://UrlBlockedError.aspx>[https://ripple.com/wp-content/themes/ripple-beta/assets/img/logo/ripple-logo-color@2x.png]

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.


________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.



--
Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<UrlBlockedError.aspx><UrlBlockedError.aspx>[https://ripple.com/wp-content/themes/ripple-beta/assets/img/logo/ripple-logo-color@2x.png]

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

Received on Thursday, 17 November 2016 14:07:28 UTC