> On Tue Jul 19 21:19:15 2011, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Whitespace Keepalive Negotiation > > FWIW, this one seems sensible for the XSF to adopt. > > I'd like to make some observations: > > 1) I think the negotiation should be more like resource binding - the > client offers a suggestion, the server sets the interval based on > that suggestion. I don't see a need for a back-and-forth where the > client's value is rejected as being out of range. >
Several things determines the interval length, in both server and client side, such as application(service type), network, client type. There may be situation both side can't agree each other's suggestion. I think a three-way talk would be better. > 2) If either party sends any data, including whitespace, the timer > MUST be restarted. > > 3) Typically, I'd expect a client to negotiate a high keepalive, and > then issue the whitespace itself, in order to control transmission > timing. (A mobile client will want to send all its keepalive traffic > at once). > > 4) Servers SHOULD use XEP-0199 or XEP-0198 to actively solicit > traffic from silent clients, and SHOULD only terminate the connection > of unresponsive clients, rather then merely silent ones. > This is just another solution and more efficient than xmpp ping. Also, I think client and server would use the same method. Thanks Season
