[Nsi-wg] Message Delivery Layer

[Jeroen van der Ham]

Hi,

The problem that I am trying to solve is the situation where the client is possibly behind a firewall/NAT/whatever, where the client is the only one capable of setting up a bidirectional TCP session.

Right now the NSI protocol breaks in that situation, because it insists on sending the acknowedgements through a separate channel that is independently setup by the server back to the client.

In my opinion the simplest way to solve that is indeed to make the callback optional and allow clients to poll for updates. The reserveConfirmed may or may not be sent. But getting it failed to deliver would not trigger a fault.

Jeroen.

On 7 Dec 2012, at 10:26, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> On Thu, 6 Dec 2012, Jeroen van der Ham wrote:
> 
>> A feasible first step in my opinion would be to make acknowledgements optional. Combined with a good query interface this already makes it possible to operate a client NSA behind a firewall.
> 
> Are you suggesting to make callback optional and resolve to polling for updates? I.e., never getting a reserveConfirmed message from a reserve request.
> 
> (btw. I think polling is completely acceptable - most people who have build a distributed system with events are painfully aware that they sometime disappear and that one will have to resolve to polling as a fallback).
> 
> OR:
> 
> Thowing out the callback scheme, i.e., getting a reserveConfirmed as the direct reply to a reseve request. This will mean some potential long-standing requests (not that it is a problem), probabaly some minutes.
> 
> This can also be optional (replyTo -> yes to callback, no replyTo -> direct reply). I'd prefer not to have this dual behavior due to implementation complexity.
> 
> --
> 
> Originally we chose to have the callbacks as some of the commands could take a very long time to complete. I think this was especially for provision, which would not trigger until the link came up (could be weeks), however with the notification mechanism in NSI2, that is no longer the case (provisionConfirmed now indicates that all NSAs have acknowledged the provision request).
> 
> If we are willing to handle request delays of a couple of minutes (most will be faster), we could forgo the callbacks for requests, and only deal with callbacks for notifications like active and forcedEnd.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg