perfsonar development work

[Jason Zurawski <>]

Ulisses;


> +TOPSDataRequest (client requests some or all of TOPS db info)
> +       TOPSDataResponse
> +
> +
>
> Ok
>
> +TOPSClientRegisterRequest (client 'registers' with the TOPS, 
>
> please note that what I tried to explain in the description I sent is that
> the TOPSDataRequest also acts as a registration by including a time to live 
> field
> for the data request, this way the server will push the data each time the 
> requested
> data changes until the ttl expires
>
> +                               TOPS provides
> +                               some sort of 'key' back [client responsible 
> for
> +                               updating own key so it doesn't expire?  Will 
> it
> +                               expire?].  Will data push to registered 
> clients
> +                               when changes occur [triggers], the list of
> +                               registered clients will exist on the TOPS
> +                               somwhere?)
>
>   

I understand that you want to save the amount of messages that need to 
be defined and recognized, but it seems a little complex to roll two 
functionalities (requesting data directly, registering for push data at 
a later time) into a single message.  Perhaps you can explain why you 
think a single message accomplishes this goal better?


> +       TOPSClientRegisterResponse
>
> IMHO, not needed
>   

Absolutely this is needed, how would it be possible to tell if this 
succeeded or failed?  Even if its just a simple return of an error code, 
it counts as a message type.

> +
> +
> +
> +       [We may need submessages in this category, imitating the LS:]
> +
> +               ClientRegisterWithTOPS
> +                       TOPSClientResponseFromTOPS
> +
> +               ClientUpdateRegistrationWithTOPS
> +                       TOPSClientResponseFromTOPS
> +
> +               ClientKeepaliveWithTOPS
> +                       TOPSClientResponseFromTOPS
> +
> +               ClientDe-registerWithTOPS
> +                       TOPSClientResponseFromTOPS
> +
>
> I would avoid that much amount of messages, IMHO I think that what i propose
> is just enough for now and implements the required funcionality.
>
>
>   

Right, you are proposing enough to get by for now, but these are all 
valid use cases (if we are to follow the general template of how the LS 
manages data/client interaction) and will eventually need to be dealt 
with.  If your system will periodically 'clean up' the client 
registrations by TTL it may be nice to have the ability to either 
're-request' with the same key (thus updating the TTL) either through 
the standard registration mechanism or through some sort of keepalive.  
I suppose de-registration is not required but may be nice if a client 
wishes to be polite and not continue to utilize system resources when it 
knows it will be going offline before a TTL is exceeded.

-jason