Post when you host

[Toll]

Hmm. Of course, I'd prefer the timeout to work properly myself in order to prevent griefing (even though I doubt it'll be a real problem, better safe than sorry). Failing that though, yeah, ditching a matching customer ID on reconnect sounds like a good idea. Out of curiosity though (and I'd understand if you wouldn't want to answer it), how are customer ID's generated? Hashed off of the key somehow, or is it a random number assigned on install, or something else?

[keith.lamothe]

Hmm. Of course, I'd prefer the timeout to work properly myself in order to prevent griefing (even though I doubt it'll be a real problem, better safe than sorry). Failing that though, yeah, ditching a matching customer ID on reconnect sounds like a good idea. Out of curiosity though (and I'd understand if you wouldn't want to answer it), how are customer ID's generated? Hashed off of the key somehow, or is it a random number assigned on install, or something else?

It's the first number of your key (which isn't random, but sequentially issued).

[tigersfan]

I'm ok with it dropping the current ID if you try to log in with the same one. As for the greifing, when you get to that point, allowing a server owner to ban by reg code will make that pretty much go away, I would think.

[keith.lamothe]

I'm ok with it dropping the current ID if you try to log in with the same one. As for the greifing, when you get to that point, allowing a server owner to ban by reg code will make that pretty much go away, I would think.

Well, the server is never sent your full key, just the customer ID, and if you ban'd the customer ID of someone trying to log in as you to boot you off your connection, you'd be banning yourself too

But in order to do that griefing attack, the griefer would either have to know your customer ID and keygen a key with the same ID and use that, or hack the client or their outgoing network traffic to transmit a different customer ID (yours) than the one they're using.  I could probably add a way to tell the server to not allow boot-the-first reconnects from a different IP or something like that.  Of course, griefer can spoof their own IP too, but I don't think the server's response packets would make it back to them (so it'd just be blind kicking someone else).

[superking]

I cant get back in, thats pretty lame

[Toll]

There's a mantis-issue about the reconnect-problem as well. I assume it'd be possible to reconnect if I restart the server (which I've been thinking of doing for that specific reason).

[Toll]

Seems okay to me to disconnecting someone if you reconnect with the same customer ID and IP-address. Is either of those sent to clients in any way anyway (or, in other words, is it feasible to get them by packetsniffing)?

EDIT: Just a thought about IP-address though... What if someone gets DC'd by their ISP? That could easilly change the IP-address. So yeah, the timeout still need to work in the end, of course.

[keith.lamothe]

Seems okay to me to disconnecting someone if you reconnect with the same customer ID and IP-address. Is either of those sent to clients in any way anyway (or, in other words, is it feasible to get them by packetsniffing)?

The customer ID is included in the PlayerAccount objects that are sent to everyone but I could get it to not do that.  IP address is never sent to other clients.

Someone with a man-in-the-middle between the server and the other client(s) would be able to see the other client IPs, of course, and all their traffic.

EDIT: Just a thought about IP-address though... What if someone gets DC'd by their ISP? That could easilly change the IP-address. So yeah, the timeout still need to work in the end, of course.

Right, the timeout needs to work anyway, and doing at least a brute force approach is certainly possible: if the server hasn't gotten anything from you that indicates your sim is still running in X seconds, drop the connection, with X possibly being configurable per client though I don't know if it would be needed (just standing there still sends _some_ messages so it wouldn't drop you for simply not doing anything).

Another possibility is being able to (optionally) set a password on your customer-id/username pair.  Then any authenticated login attempt could boot a previous connection without us needing to worry much about griefing.  Unless of course someone gets your password, and I'm not really all that keen on trying to incorporate genuinely encrypted/secure traffic for just this one thing.  If I had to, sure, but I'm not sure of the importance.

[Toll]

Encrypting traffic might be taking things a bit far, yeah. I see nothing wrong with encrypting generally, but unless there's a readily-available package to use in order to do away with coding-time, it's probably not worth it in this case. Plus, it'd add another layer of potential bugs, even if the potential is slim.

And yeah, unless the customer ID is used in any fashion player-side, I'd personally prefer it wouldn't be sent, seeing how it's part of a key and all. Sure, it'll always be accessible to people hosting servers (either through packetsniffing or savefile-harvesting), but at least that's just one person and not everyone you play with. Might just be my paranoia speaking though.

[keith.lamothe]

And yeah, unless the customer ID is used in any fashion player-side, I'd personally prefer it wouldn't be sent, seeing how it's part of a key and all. Sure, it'll always be accessible to people hosting servers (either through packetsniffing or savefile-harvesting), but at least that's just one person and not everyone you play with. Might just be my paranoia speaking though.

It's quite reasonable to not want it sent around   FYI, the number you see next to a person's username in the game is their PlayerAccount object's primary key on that server, which are created sequentially as new player accounts are created (for customerID/username pairs) in that particular world.  I just appended it for now so that there was always a way to tell people apart if they had the same username.

[Dizzard]

I'm playing around in Toll's world at the moment, I think everyone is sleeping.

Are you all afk or is that just what happens when you log out?

[Toll]

The problem de'jour seem to be that the whole "logout" thing isn't working So yeah, most (if not all at this point) of the people in there aren't actually there. For instance, I probably have three people in there just standing around.

Another effect of this is that once you leave the world, you can't re-enter it with the same username. Hopefully that'll be fixed by next version? Figured I'd restart the server after I have a bite to eat though.

[keith.lamothe]

Another effect of this is that once you leave the world, you can't re-enter it with the same username. Hopefully that'll be fixed by next version?

Yea, I've got a couple things on my list that should take care of that.  Chris isn't in the office today so not sure when the next version will be, though.

[Toll]

Well, it'll come when it comes. Problems are to be expected in alphas and betas

[keith.lamothe]

Well, it'll come when it comes. Problems are to be expected in alphas and betas

Yes, definitely.  Actually I'm kind of surprised that there haven't been worse problems.  Josh and Chris and I probably logged a total of about 6 hours of testing on very recent versions of the server (probably about 12 more in previous tests) so I guess it stands to reason that the thing isn't melting down, but I expected worse   It doesn't surprise me that logout and reconnection are the main issue, as we just didn't think to heavily test those.