[2012-11-13 19:47:52] <en_dator> well, we have played with two ideas, one is alive, to let hub/client test to see if the other end is still there, and the other is to let the hub act as a relay for sending adc commands
[2012-11-13 19:48:46] <Pretorian> Aren't those in the forum?
[2012-11-13 19:49:04] <Pretorian> For 1), can't you just send a \n?
[2012-11-13 19:49:20] <en_dator> only in flexhub forum atm i think
[2012-11-13 19:49:32] <Yorhel> Hub doesn't reply to a \n
[2012-11-13 19:49:42] <en_dator> and client does not either
[2012-11-13 19:49:47] <Pretorian> You don't need a "reply".
[2012-11-13 19:49:53] <en_dator> i want a reply
[2012-11-13 19:49:57] <Pretorian> Why?
[2012-11-13 19:49:57] <en_dator> thats the purpose
[2012-11-13 19:50:06] <Yorhel> Yes, definitely
[2012-11-13 19:50:07] <Pretorian> What's the reply going to tell you?
[2012-11-13 19:50:20] <en_dator> that someone is alive at the other end
[2012-11-13 19:50:24] <Yorhel> In fact, I proposed a similar extension on the forum some time ago. Never looked at it again, though
[2012-11-13 19:50:52] <Pretorian> If you try and send something on a TCP socket and you aren't connected, you'll get an error.
[2012-11-13 19:51:02] <en_dator> correct
[2012-11-13 19:51:06] <en_dator> at least almost
[2012-11-13 19:51:09] <Pretorian> So, "\n".
[2012-11-13 19:51:14] <en_dator> on windows thats not always true
[2012-11-13 19:51:30] <Yorhel> I really, *really* love the ping information that IRC clients give you. Tells you approximately how long you need to wait for for your chat message to pass through
[2012-11-13 19:51:39] <Yorhel> And for that you need a reply
[2012-11-13 19:51:56] <en_dator> and also the socket might still be there, but the program might be frozen or dead
[2012-11-13 19:51:58] <Yorhel> And the IRC protocol does that with ping messages
[2012-11-13 19:52:29] <Pretorian> Though, if the application is dead, won't the socket hang?
[2012-11-13 19:52:40] <Pretorian> dead/frozen
[2012-11-13 19:52:46] <en_dator> in a way yes
[2012-11-13 19:52:53] <Pretorian> I.e, you'll have to wait for the timeout.
[2012-11-13 19:52:53] <en_dator> but to the other end it still looks connected
[2012-11-13 19:53:56] <Pretorian> A and B are connected. B freezes/crashes. A sends "\n". A's socket maanger will report (after a while) that the information couldn't be sent on the socket because of X.
[2012-11-13 19:54:20] <en_dator> thats the ideal case yes
[2012-11-13 19:54:46] <Pretorian> What's the other cases?
[2012-11-13 19:54:50] <en_dator>
- [2012-11-12 17:40:13 | 83.142.1.169 | SE] <endator> that depends on what hub they are in, nmdc or adc
- [2012-11-12 22:31:22] *** An existing connection was forcibly closed by the remote host.
[2012-11-13 19:55:02] <en_dator> i talked one line in a hub, short after it crashed
[2012-11-13 19:55:06] <Pretorian> We are talking about ADC.
[2012-11-13 19:55:21] <Pretorian> I don't care about NMDC.
[2012-11-13 19:55:22] <en_dator> i didnt notice that until after i got home a few hours later and killed the process
[2012-11-13 19:55:45] <Pretorian> ADC or NMDC hub? Does the client send a \n?
[2012-11-13 19:55:50] <en_dator> so the client message, the second row only hppened when i killed the hub
[2012-11-13 19:56:12] <en_dator> thats a flexhub and the connection is with apex on adc
[2012-11-13 19:56:24] <Pretorian> Does the client send a \n?
[2012-11-13 19:56:57] <en_dator> dont know
[2012-11-13 19:57:05] <Pretorian> Please check that.
[2012-11-13 19:57:22] <Pretorian> DC++ used to send \n but I don't know anymore.
[2012-11-13 19:57:29] <Pretorian> (And "|" in NMDC.)
[2012-11-13 19:58:00] <Pretorian> A \n or | vs an actual ADC/NMDC command are no different...
[2012-11-13 19:58:10] <Pretorian> It's still "data on the socket".
[2012-11-13 19:58:11] <en_dator> i cant remember seeing that being sent
[2012-11-13 19:58:46] <Pretorian> So the solution with a "new command" is pointless; just send | or \n.
[2012-11-13 19:59:30] <en_dator> i dont think that will work, but i promise to test it again
[2012-11-13 19:59:32] <Pretorian> If you want the reply... Well, how do you as a hub determine that the client got their reply?
[2012-11-13 19:59:58] <Pretorian> It's the age of problem of "did you get my reply", "yeah, I got the reply. did you get this?"
[2012-11-13 20:00:09] <Pretorian> At some point you just have to... stop.
[2012-11-13 20:02:55] <Pretorian> Also, how do you know that the hub got the client's ping?
[2012-11-13 20:03:37] <Pretorian> I suppose hub implementations could simply repond with a "\n" if they get a "\n" and you're golden, mhm?
[2012-11-13 20:03:40] <en_dator> one end initiate with sending alive token,, other end replies with alive token
[2012-11-13 20:04:16] <en_dator> or better explained
Can be hub or client initiated:
Hub sends: ILIV TOtoken
Client sends: HLIV <sid> TOtoken
Client sends HLIV <sid> TOtoken
Hub sends: ILIV TOtoken
[2012-11-13 20:04:42] <Pretorian> Sigh...
Hub sends: \n
Client sends: \n
Client sends: \n
Hub sends: \n
[2012-11-13 20:04:42] <en_dator> its a very very small extension
[2012-11-13 20:05:22] <en_dator> yes i know Pretorian, but in this way it gets a real purpose
[2012-11-13 20:05:51] <Pretorian> You literally gain nothing.
[2012-11-13 20:06:17] <Yorhel> Pretorian: ADC doesn't at all specify the semantics of the empty command (\n), so you can't rely on that to get you a reply.
[2012-11-13 20:06:49] <Yorhel> And like I mentioned before, having a ping/pong message is definitely useful
[2012-11-13 20:06:49] <Pretorian> Yorhel: ADC specify an empty command, just not that you can rely on getting a reply.
[2012-11-13 20:07:06] <Yorhel> Which is exactly why the empty command is useless
[2012-11-13 20:07:42] <Pretorian> So, the correct thing is to say that "anyone who gets a \n should reply as such also".
[2012-11-13 20:07:55] <Yorhel> That'd be nice, but kinda late at this point
[2012-11-13 20:08:04] <Yorhel> Erm, actually, no. that'd be a bad idea
[2012-11-13 20:08:21] <Yorhel> A very bad idea, even, as you get an infinite supply of \n's
[2012-11-13 20:08:35] <Pretorian> Ehh, no.
[2012-11-13 20:09:20] <Pretorian> "If \n was sent within X minutes don't reply".
[2012-11-13 20:09:46] <Pretorian> You're anyway going to implement this command to be sent every X minutes.
[2012-11-13 20:10:33] <Yorhel> It also has the downside that if both hub/client happen to have similar timers, they may send it simultaneusly and not as a reply to each other - thus losing any timing information you may have gained by a request-response type message
[2012-11-13 20:10:46] <Yorhel> (And it's exactly that timing information that I care about)
[2012-11-13 20:11:29] <Pretorian> Similar timers? WTF? You get data from the other side! Reset your timer!
[2012-11-13 20:12:01] <Yorhel> I want a lag detection. If you can provide me with a solution based on \n I'd be more than happy
[2012-11-13 20:12:01] <Pretorian> if no data within X minutes, send command
[2012-11-13 20:12:18] <Pretorian> Lag detection is different from keep-alive.
[2012-11-13 20:12:33] <Yorhel> Yes
[2012-11-13 20:12:37] <Pretorian> You would then have to include time in the commands.
[2012-11-13 20:12:40] <Yorhel> No
[2012-11-13 20:12:56] <Yorhel> Just a simple request/response is all you need
[2012-11-13 20:12:58] <en_dator> time or token
[2012-11-13 20:13:14] <Yorhel> token would be the best approach, indeed
[2012-11-13 20:13:29] <en_dator> at least an semi-unique identifier, else it'd be a little pointless
[2012-11-13 20:14:04] <Yorhel> You could do without, as long as you can differentiate between a ping request and a ping response
[2012-11-13 20:14:10] <Pretorian> Both parties may be interested in the time, not just the initial sender.
[2012-11-13 20:14:19] <en_dator> true
[2012-11-13 20:15:49] <en_dator> but i think for that to work out its much easier if each end initiate it if/when they want to know it
[2012-11-13 20:16:21] <Yorhel> Time synchronisation is a hard problem in general, I'm unsure how including the time in the message is going to make it easier on either party
[2012-11-13 20:16:41] <Yorhel> Especially when a simple ping/pong would suffice
[2012-11-13 20:17:26] <Pretorian> The question about lag detection is also difficult on the grounds that the hub may want to prioritize it.
[2012-11-13 20:17:42] <Pretorian> E.g., you might have a different "lag" for text messages than search requests.
[2012-11-13 20:17:58] <Yorhel> That's possible, but acceptable
[2012-11-13 20:18:17] <Pretorian> Then you aren't actually measuring anything, beyond your ping/pong.
[2012-11-13 20:18:30] <Pretorian> Which are... almost pointless by themselves.
[2012-11-13 20:18:51] <Yorhel> And there'd be a very strong correlation between that ping/pong and the message lag in by far most of the cases
[2012-11-13 20:19:57] <Yorhel> Just because it's not directly related doesn't mean it's useless
[2012-11-13 20:20:37] <Pretorian> You aren't measuring the information you want to actually make sure is getting there in a timely fashion.
[2012-11-13 20:20:50] <Pretorian> (MSG is actually different since we have the time parameter.)
[2012-11-13 20:21:25] <en_dator> yes, but here we dont know the time difference between client and hub
[2012-11-13 20:22:44] <Yorhel> Like I said, I absolutely *LOVE* the lag detection used in IRC, which works exactly as a simple ping/pong message over the TCP connection
[2012-11-13 20:22:52] <Yorhel> It's incredibly useful
[2012-11-13 20:23:11] <Pretorian> (Command note: there is no need to have a named parameter that you are always going to send.)
[2012-11-13 20:23:31] <Pretorian> (I.e., it should be positional.)
[2012-11-13 20:23:36] <Pretorian> (Remove the 'TO'.)
[2012-11-13 20:23:48] <Yorhel> disregarding that because what you measure and what you want to measure may not necessarily be equivalent in all cases is a pity
[2012-11-13 20:24:13] <en_dator> thats a good point
[2012-11-13 20:24:35] <en_dator> think we added that because of the likelyness with other commands using tokens have the TO
[2012-11-13 20:24:43] <Yorhel> Especially considering that, in most hubs, I'd expect the buffers to be empty most of the time. Priority queueing isn't going to make much of a difference if a hub decided to do that
[2012-11-13 20:24:52] <Yorhel> Unless a hub intentionally delays chat messages, but that'd be quite stupid
[2012-11-13 20:25:01] <en_dator> no, we do that all the time
[2012-11-13 20:25:10] <Pretorian> Yorhel: I know some NMDC hubs intentionally delay search requests.
[2012-11-13 20:25:19] <en_dator> no huge delays though, but still
[2012-11-13 20:25:43] <Yorhel> Searches are quite different. In some hubs you should be happy if your search came through in the first place >_>
[2012-11-13 20:27:12] <Pretorian> If a client sends "foobar" as token and the hub responds (sometime later) with "barfoo" as token, what's the correct action?
[2012-11-13 20:27:44] <Yorhel> Ignore?
[2012-11-13 20:28:02] <Pretorian> Continue to wait forever for the foobar token?
[2012-11-13 20:28:12] <en_dator> those are two different commands and should be handled as such
[2012-11-13 20:28:44] <Yorhel> If the hub doesn't correctly reply to your ping, then yes you'll have infinite lag
[2012-11-13 20:28:58] <en_dator> if client receives befoo it should reply to that, the fact that the hub choose to ignore the first foobar is not relevant
[2012-11-13 20:29:09] <Pretorian> If the discussion has moved away from a keepalive (i.e., use \n for keepalive) then that's fine. If the discussion is still on on keepalive, then you have to decide what to do.
[2012-11-13 20:29:15] <en_dator> not befoo, barfoo
[2012-11-13 20:29:31] <Yorhel> On keepalive: I fully agree with Pretorian, \n works perfectly fine
[2012-11-13 20:29:52] <Pretorian> You should do *something* if you don't get your keepalive reply. Like, disconnect/reconnect.
[2012-11-13 20:30:04] <ShadoWx> hi
[2012-11-13 20:30:10] <ShadoWx> could u help me?)
[2012-11-13 20:30:25] <Pretorian> ShadoWx: Always just ask.
[2012-11-13 20:30:35] <Pretorian> You don't need to ask to ask.
[2012-11-13 20:30:47] <Yorhel> Pretorian: I wouldn't use it for keepalive
tcp works fine for that as you mentioned earlier (at least, that's my impression, too)
[2012-11-13 20:30:59] <Yorhel> Lag detection is mainly for visual feedback
[2012-11-13 20:31:25] <Pretorian> Yorhel: Is anyone going to use that, though? You're doing pings on IRC?
[2012-11-13 20:31:42] <en_dator> i dont agree, for all hubs i have been involved in the question of ghosting users has always been brought up more than once - hence I'd say that there is a valid issue
[2012-11-13 20:31:52] <Yorhel> My IRC client auto-pings every so often and tells me the timing if it's larger than 0.5s