Comments (10)
Oh, this is a good point. I believe in initial thoughts about this we had defined a keep-alive proto/packet... but were dissuaded from that path for reasons which aren't in my memory banks today :( I think minus the keepalive officially being a packet/message, you can certainly just heartbeat requests on a reasonable timer.
It seems likely that in some deployments you may go quite some time between 'changes' on devices, so your heartbeats may just not get returned data for long intervals of time. Decisions about: "is this connection dead? Is the far end overworked and can't reply, but still there??" seem like they get fixed at the TCP layer, mostly. It would be unfortunate if the client here decided after N no-replies to bounce the session, that is unnecessary work on the overall system, and possibly a confusing behavior :(
I think some thought/guidance on the system here is in order... I suspect that at least the idea that:
- start session, ask for history be requested ("hi, give me everything since 27 days ago!")
- delivery from server -> client of the backlog avaialble
- sending of 'record request' with timestamp=record-received-timestamp
- process replies if any are received
- goto 2
is a good starting point, for me anyway, in the discussion.
from gnsi.
OK, 2 suggests that it is not streaming; ie: that it sends stuff, waits for another request, sends stuff, repeat, while I previously thought that 2 was essentially ignored, like:
- connect and send initial recordrequest (ie: RecordSubscribe)
- wait for/receive msgs,
- send keepalive if necessary
- goto 1
from gnsi.
I think in the current proposal there is no difference between a keep-alive and request message asking for records. At least the server treats every RecordRequest
message as The client is asking something, let me check if I have something to be sent
, it sends RecordResponses if there is any new event which happened after the timestamp in the message. It also uses this message as an indication that the client is still alive and consuming records. As @morrowc mentioned, some of the concerns about the liveness of the far-end can be handled by TCP so I am not sure if we need an application level keep-alive mechanism.
from gnsi.
I disagree; its not clear to me.
The suggested semantics are "keep sending stuff as record sources post them, until a timeout or socket closure occurs".
Or, is it "send stuff, wait for a RRequest and send records from that timestamp, rinse repeat, until a timeout or socket closure occurs."
Or, is it some hybrid of those, such as "send stuff as record sources post them, when a RRequest arrives possibly backup to that date and begin sending records from there, until a timeout or socket closure occurs."
If TCP handles liveliness, then the entire timeout mechanism is unnecessary or maybe it can be defined based on the persistent inability to enqueue new records for sending. Still must define what happens if a RRequest arrives after the initial RecordSubscribe.
from gnsi.
I think the current model is
Or, is it "send stuff, wait for a RRequest and send records from that timestamp, rinse repeat, until a timeout or socket closure occurs."
from gnsi.
The comments from morrowc implied: "keep sending stuff as record sources post them, until a timeout or socket closure occurs".
I have no confidence that you or I know which is correct.
from gnsi.
It's almost certainly the case that I imagined this service in a totally incorrect manner :(
(this is probably where my original keep-alive type handling was supposed to be happening... that's since morphed)
Ok, so originally I viewed this as:
- client connects to the server/device and asks for accounting records from at least time-X.
- server/device sends all records in bunch (how that happens on the wire isn't important to me).
- server/device keeps on sending new logs as they are created
- the client was responsible to say periodically: "Still here!!" (keep-alive behavior)
Marcus, I think, dissuaded me from the keepalive method/thought process, effectively saying: "Hey, we have TCP keepalives, no worries!"
Now we believe/built a world where we are thinking the client will periodically tell the server/device: "Hey, since X more logs pls!"
I think that change is 'wrong thinking' on my part ;( If we agree on that (which would be awesome) then we just need to sort out expectations. I think the comment thread here says:
"Client connects, asks for history, Device streams records from history and then just sends records as the are created forever... if TCP timeouts happen go to the start"
That sounds, to me like the right thing, that a 'keep alive' application level function isn't necessary.
Now, how do we fix the documentation ? :)
from gnsi.
I agree!
An implementation might also reset the session if the output queue remains full for too long (the "zero window" problem). That covers TCP remaining connect, but the remote being dead. also see ietf draft-chen-idr-tcp-user-timeout.
from gnsi.
We are fine with this approach, can we close this issue ? We can raise a PR to update the documentation.
from gnsi.
Please review #148 to address this behavioral change. TiA
from gnsi.
Related Issues (20)
- authz: Clarity needed for few operations DURING Rotate() in progress HOT 3
- Certz does not have counters per-profile HOT 4
- gnsi.accounting.v1 SessionInfo.system_address HOT 2
- RecordResponse.ServiceStatus only applies to GrpcService
- Use of json for policy in authz without a protobuf alternative is obtuse HOT 2
- certz default profiles HOT 3
- Inconsistency between documentation and protobuf definition for groups with members
- authz ProbeResponse action enum HOT 2
- pathz grpcurl reflection: included an unresolvable reference to ".gnmi.Path" HOT 1
- Certz should permit delivery of a certificate bundle as a PKCS#7 encoded string.
- Need clarity on trust_bundle structure in certz.proto HOT 1
- Need clarity on authentication-policy under certz.proto HOT 1
- Need clarity on credentialz.proto host certificate rotation
- Description of GrpcService.config_metadata is too vague HOT 8
- Description for gnsi.accounting.CommandService.cmd and cmd_args seem too vague HOT 2
- Add gnsi.accounting is_truncated flags? HOT 2
- gnsi.account missing telemetry HOT 1
- gnsi.accounting.SessionInfo is lacking in various ways HOT 3
- authz default behavior should not be vendor prerogative HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gnsi.