Source port idea! - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Source port idea!

Pages (12): « First ... « 8 9 10 [11] 12 »

Author

All times are GMT. The time now is 20:43.

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

@Bzlut3
Qt already implements all the functionality you would need to communicate using HTTP. I actually think that the need for Doomseeker to use UDP is rather unfortunate - it shows up the unnecessary limitations of the services you are trying to communicate with.

12-07-12 18:19 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

@Ladna & DaniJ:

1- Don't fix what isn't broken.
2- Again, not functionality *we* gain. (yes, I'm being selfish.) Plus, you're both referring to portability, not functionality.
3- Think I phrased that wrong. Additional work doesn't justify the end result of: "it's the same thing, just.. different."
4/5- @DaniJ: Your opinion of an unnecessary limitation is to allow "name faking" - something which has been a complaint that has been common in ZDaemon for ages. It's also something I consider an unnecessary flaw.
4/5- @Ladna: Since you're 'banned' and "don't care" I'll assume that you have no idea what goes on. It has some similarities to the design in kerberos.

Both of you assume that the launcher should literally be just a server browser. Since we can (and have) provided more than just a server browser, turning it into 'just a server browser' is a loss of functionality & features (and yes, I consider blocking name faking a feature), and not in our best interests.

@Ladna:
This isn't community-driven design. This is you guys trying to impose your design opinions when they are not being welcomed.

DaniJ said:
it shows up the unnecessary limitations of the services you are trying to communicate with.

Pretty sure that up until this point (and even at this point) he's not yet trying to communicate with any tcp-based services. So how could it be an unnecessary limitation? Besides, the servers all talk via UDP, so querying them individually would still require UDP code. Seems like unnecessary additional work to support TCP-based protocols when you're already doing it via UDP. Now, if you want to support querying a TCP-based master, then you add your TCP-based code.

(edit: added response to DaniJ's last comment @Blzut3)

Last edited by Lyfe on 12-07-12 at 18:33

12-07-12 18:27 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

I don't see how any of this precludes features in your launcher. You can still implement your proprietary UDP protocol to do all your user client server interaction stuff yet query servers over HTTP.

Name faking is irrelevant because it is a concern at a different level of abstraction (well, it should be).

12-07-12 18:30 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

DaniJ said:
I don't see how any of this precludes features in your launcher. You can still implement your proprietary UDP protocol to do all your user client server interaction stuff yet query servers over HTTP.

Name faking is irrelevant because it is a concern at a different level of abstraction (well, it should be).

For querying of servers, yes. But joining a server? (Which ultimately is what we all want to do.) I suppose we ultimately have to get technical on the difference. But what good is querying a server if you cannot join it (ignoring password protected games for the moment)?

So, given that querying is pointless without ability to join, i suggest that querying and joining go hand-in-hand.

How can it possibly be a concern at a different level of abstraction?

You want verification that the player who joined the server is the player who authenticated against the master (and thus owner of the name). This requires data that all 3 systems (master, client & server) must have. Not necessarily the same data, but verifiable. Please, explain this to me, because right now, I'm of the opinion you're making it up.

12-07-12 18:41 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Why do you need a UDP protocol to join a game session when the session is joined via a separate launcher application?

It seems to me that what you actually want to do is to instruct the ZDaemon process (which may or may not be running at the time) to connect to the server which the launcher has identified. I'm presuming that you currently do this rather differently?

Lyfe said:
Pretty sure that up until this point (and even at this point) he's not yet trying to communicate with any tcp-based services. So how could it be an unnecessary limitation? Besides, the servers all talk via UDP, so querying them individually would still require UDP code. Seems like unnecessary additional work to support TCP-based protocols when you're already doing it via UDP. Now, if you want to support querying a TCP-based master, then you add your TCP-based code.

You misunderstand. The unnecessary limitation is that a client (note != user) cannot even query the availability of servers without knowledge of your proprietary protocol.

Querying servers and joining them, whilst closely related functionally are actually different concepts with different needs. To join a server I must authenticate, this is given. However, to query the availability of a server I should not need to authenticate because at this point in the process I do not intend to join.

It is only when the game client (thus user) means to join a server do you need to authenticate.

Granted, your launcher may be performing additional services which might well require authenticated access. However, this can be achieved by implementing your proprietary protocol like you are doing.

Sorry but your infrastructure seems somewhat confused at present.

By way of example, if I want to write an app for my mobile phone which queries the available Doomsday servers I simply parse the response from http://dengine.net/master.php?xml (or the JSON version, whichever is more convenient).

Edit: Added details to points I didn't clarify originally.

Last edited by DaniJ on 12-07-12 at 19:43

12-07-12 19:01 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

DaniJ said:
Why do you need a UDP protocol to join a game session when the session is joined via a separate launcher application?

It seems to me that what you actually want to do is to instruct the ZDaemon process (which may or may not be running at the time) to connect to the server which the launcher has identified. I'm presuming that you currently do this rather differently?

I'm not sure I understand what assumptions you're making here, nor what you're asking. So, I might be responding to something other than what you're asking.
The game session (game client <-> game server) is UDP. You are correct in that the game client gets launched based off information the launcher has identified, but are missing the detail about the launcher providing extra data to the game client for validation of the user. (How else did you think we solved the name-faking issue?)

Regarding UDP usage throughout:
We've established with a FPS client/server game, that the most effective way to send data is via UDP. If nothing else, just for latency of data.
Since the game server already uses UDP for communications with clients, it makes sense to just add a couple new packet types for sending heartbeats & receiving/sending game queries via UDP. Otherwise, you need a whole new set of network code in order to support TCP-based communications. Under the same logic, it is reasonable to derive the reason for a master & launcher to use UDP as well. Why introduce a second network layer when the first is already there?

To go back to my 'misunderstanding.' The only purpose to get a list is to query the servers. The querying of the server is still UDP, which means that HTTP support has really just added more code (independent from everything else) which must now be maintained along with the UDP code for querying you still need.
The only purpose for querying a server that you cannot join is to stalk the players on it.

So, I still find the overhead of developing an HTTP output & reader to be unnecessary, given that it still doesn't provide the functionality necessary to join a game. Thus, this unnecessary limit is derived from an unnecessary request.

12-07-12 20:17 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Lyfe said:

I'm not sure I understand what assumptions you're making here, nor what you're asking. So, I might be responding to something other than what you're asking.
The game session (game client <-> game server) is UDP. You are correct in that the game client gets launched based off information the launcher has identified, but are missing the detail about the launcher providing extra data to the game client for validation of the user. (How else did you think we solved the name-faking issue?)

This is the part I believe you are implementing incorrectly. Essentially what you are doing here amounts to privilege injection. Rather than have the launcher pass on credentials to the game client re the user which is attempting to join, instead I would pass an argument to the game client denoting the name of the user I wish to connect as (then have the game client do the authentication with the server when it tries to establish a connection).

Regarding UDP usage throughout:
We've established with a FPS client/server game, that the most effective way to send data is via UDP. If nothing else, just for latency of data.
Since the game server already uses UDP for communications with clients, it makes sense to just add a couple new packet types for sending heartbeats & receiving/sending game queries via UDP. Otherwise, you need a whole new set of network code in order to support TCP-based communications. Under the same logic, it is reasonable to derive the reason for a master & launcher to use UDP as well. Why introduce a second network layer when the first is already there?

I agree that it makes intuitive sense to implement query functionality in terms of your existing UDP based protocol, however (as I have hopefully shown) there is considerable benefit to doing this with only HTTP based systems. This would also allow Doomseeker to achieve what it intends without compromising your protocol.

12-07-12 20:25 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

DaniJ said:

This is the part I believe you are implementing incorrectly. Essentially what you are doing here amounts to privilege injection. Rather than have the launcher pass on credentials to the game client re the user which is attempting to join, instead I would pass an argument to the game client denoting the name of the user I wish to connect as (then have the game client do the authentication with the server when it tries to establish a connection).

I agree that it makes intuitive sense to implement query functionality in terms of your existing UDP based protocol, however (as I have hopefully shown) there is considerable benefit to doing this with only HTTP based systems. This would also allow Doomseeker to achieve what it intends without compromising your protocol.

Wow, I think you missed a really key part here. (Or I misunderstood you.)

Authentication of a user should NEVER go through a 3rd party (game server). It's the same problem that's addressed in protocols like kerberos. The only points of trust for a password are the client (who owns the data) and the authentication server (which knows a hashed/encrypted/whatnot version of the data). The game server should never be told a user's password.

This might be the part you're missing in the design, which is thus causing this conversation issues.

12-07-12 20:39 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

No I wasn't missing that detail. Obviously one should not depend on a third party to proxy authentication as this is a big security hole.

I was suggesting that the game client authenticates the user with the master before then trying to establish a connection with the game server.

(I should have been more explicit, sorry)

Last edited by DaniJ on 12-07-12 at 20:50

12-07-12 20:44 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

DaniJ said:
I was suggesting that the game client authenticates the user with the master before then trying to establish a connection with the game server.

I have two arguments against this (off the top of my head):
1- You're asking us to maintain two systems (twice) for no additional functionality on our side. There's an argument about keeping passwords in memory (which you don't need to do once you have a 'ticket' - kerberos term), but since a lot of users keep that stored on the computer anyway, it's half-bunk.
2- It does make it easier to pull the BS I read about on the HLDS mailing lists, where servers get attacked by malformed query packets.

Personally, I have no interest in building the adaptations necessary, since I'd rather spend time building a multi-master matchmaking server. (Master server, without a single point of failure.) Even that, however, I'm finding a lack of interest in building.

I already know Kilgore's feelings on the topic, and I can guess at the rest of the team.

And, totally understand the explicit part. I've been trying very hard to not forget to denote a server as 'game' or 'authentication'.

Side note that I glossed over:
Btw, imo, even though you "just query" /master.php?xml for your list, I still consider that an API. It's an interface which an application must be programmed to utilize. You have input, you have output. Just because the input is easy to describe and the output is easy to understand doesn't mean it's not an API that needs publishing. Plus, if one didn't know about the parameter (xml or json) that it takes, you'd be missing out on interesting functionality.

12-07-12 21:09 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Its not a case of maintaining two systems twice (I presume you mean in the sense of duplication). It is a case of segregating communications according to the level of access privilege/right of the client which instigates said communique. These would be two independent systems, each implementing a subset of the target functionality.

I do accept that at a superficial level this does make targeting game server attacks easier, however, it is only marginally so - i.e., the would-be attacker knows the IP of the server to target.

Reliance on hiding this information is already a fools economy. There is nothing stopping the would-be attacker from packet scanning an honest client to see who it communicates with.

So, the trade off is for a partially open system which can be easily extended by your users. The actual game protocol can remain closed and can be obfuscated to your hearts content. I would also argue that this in turn actually makes your protocol more secure as there is one less vector to attack.

"just query" /master.php?xml for your list, I still consider that an API

Yes it is indeed still an API. The significant difference however is that it is one which is open, self-advertising and vastly easier to take advantage of. For example, with an HTTP based system I can enter javascript directly in the address bar of any java-enabled web client to interact with the system in interesting ways. I don't even need my own process.

12-07-12 22:57 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 234
Registered: 04-10

Oh, you guys are doing something about aliasing now huh?

A little investigation (using IDE):

- the launcher gets a token from the master when logging in
- the launcher sends this token along with username and password (in plaintext) when authing to the master (this actually happens every 10 minutes)
- the launcher generates a base64-encoded hash; does not require an internet connection
- the launcher spawns the client, passing the hash as the "-up" parameter and the username as the "+name" parameter
- the client gets a token from the server
- the client sends this token along with the username & the hash to the server
- the hash is different each time (seemingly, anyway)
- leaving "-up" unchanged and switching out the value of "+name" does not work
- hashes expire

These are things I think are probably true, but I can't verify:

- I think the server is the one that terminates the connection if the name does not match
- I think the server contacts the master for verification

These are some unanswered questions:

- Why not just have the master generate the auth hash, since they expire anyway?
- What is changed to make the auth hash different?
- Are launchers seeded by the master? (EDIT: No, definitely not. It's still possible that the master/launcher token is used in hash generation though).
- Given that the auth hash is generated seemingly uniquely by the launcher, how does anything else use it for authentication?

This illuminates ZDaemon's reason for not wanting to support Doomseeker (sort of, because the Doomseeker stuff happened way before this feature was implemented). It looks like it relies on the launcher to generate suitable auth hashes for the server, and since ZDaemon only trusts 2 launchers (ZDaemon Launcher and IDE), it can mandate that the user be logged into the ZDaemon master before passing an auth hash. If Doomseeker were allowed to generate auth hashes, it would essentially be a forgery machine.

All that said, it would've been nice if the ZDaemon devs (Lyfe & phenex2) posting here would have explained it without me having to wireshark.

===

Lyfe said:

Why introduce a second network layer when the first is already there?

This is really not even close to as hard as you imply. Using libcurl is extremely easy.

It's also worth pointing out that HTTP servers have all kinds of ways of dealing with heavy load and attacks. There's no way the ZDaemon master is anywhere near as resilient as Apache, and mirroring is hilariously easy to do with HTTP servers. To be specific, yes, this is a feature of switching to HTTP: your server gets better and you can mirror. Server resiliency is clearly something ZDaemon prizes; even in this thread you guys have said you don't want to open the UDP API because it would open the master up to attacks, and you're willing to spend resources on obfuscating it. And you yourself just said you'd be interested in mirroring.

Lyfe said:

This isn't community-driven design. This is you guys trying to impose your design opinions when they are not being welcomed.

I think you misunderstand the current context of the discussion. It goes something like this:

Blzut3: I want to support ZDaemon in Doomseeker.
ZDaemon: Nope.
Blzut3: How come?
ZDaemon: Well...
1. The service you were using (the PHP script) was broken, and we don't want to fix it.
2. We use a proprietary UDP API, we'd rather not open it up, and if you ever figure it out we'll change it.
3. We don't want to have to work with you to keep Doomseeker updated, and we don't want to switch to an open format.
4. We can't trust open source launchers.
Everyone else: We can solve those problems easily! Let's work together:
1. We agree, maintaining stuff forever sucks. This wouldn't be a problem if your API were open though.
2. There's no reason for you to keep your API closed, and obfuscating it is not nice.
3. Switching to an open format would be extremely easy, much easier than obfuscating the protocol every time someone reverse engineers it, and you'd reap the benefit of world-class server resiliency and multi-master matchmaking.
4. You don't have to, just have the master generate the auth hash.

You might say, "but Ladna, you could just hand out auth hashes then", but I'm pretty sure I can already do that.

Last edited by Ladna on 12-08-12 at 00:59

12-08-12 00:41 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

@DaniJ:
I was going to continue on this discussion, but Ladna made it obvious that he's going to keep pushing until he gets his answer. Which I don't want to give. So I'm going back to playing games with friends, and my next jack&coke. Gotta see what this Forge game is all about.

@Ladna:
For someone who doesn't care, that's an awful lot of digging.
Only point you've made is that I fail to remember parts of a protocol I haven't worked with in 10 months. (Quite literally. Feb 17 was the last entry in my repo logs for the mac query tool.) And that it's not as simple as it seems at first glance. Just so you're aware, even if you do reverse it, you wouldn't be able to use a 3rd party launcher as a hash forgery machine. If you get that far, you'll understand why. But I have a feeling that you're going to go back to working on other stuff more important to your heart than reversing the ZDaemon protocols.

I do have a decent mind for network security. While I don't agree with all the decisions that end up in zdaemon for 'security' reasons, I do get asked for my input on many of them. But that's what the back & forth arguments are for. In this case, it went back & forth, and I eventually conceded, realizing that it did achieve the goal (verification of that a user on a server is the same user who logged into the master).

And yes, I know it would've been easier to protect the whole damn network transmission by wrapping it into an ssl session (which yes, can be done over udp). But I'm lazy, and let someone else build this part.

12-08-12 01:50 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 234
Registered: 04-10

Haha. To be honest, it only took me around an hour. It would have been less time, but I chose some server that wanted me to download like 800MB of WADs. But no you're right, I don't have any further interest in it.

When I say I don't care what ZDaemon does, I mean I don't care what the project does. You guys can run tournaments, enforce your rules, add features, blah blah blah blah. I quit that community a long time ago.

I am a part of the Doomworld community though, and when ZDaemon devs come through here making claims with nothing to back them up, I'll question them. I still don't understand why ZDaemon wouldn't allow Doomseeker support, and I guess no one's gonna explain it to me. That's fine, and if a ZDaemon dev tries to imply that it's Blzut3's perceived rudeness that "forced" ZDaemon to disallow it, I'll point out that's not true. I'll say as far as I know, there's no technical reason for ZDaemon's stance, it seems more like an issue of control. Which, again, is fine, but it's a little silly I have to do shit like analyze network traffic to figure that out.

This is sort of a pattern. We debated the reasoning behind ZDaemon's source being closed, and we eventually got to the bottom of it: you guys want total control over your community. We debated the reasoning behind ZDaemon's protocols being closed and (actively?) obfuscated, and we eventually got to the bottom of it: you guys want total control over your community.

Which makes me realize we've been debating the same thing in various different ways for a while. I've been extolling the values of cooperation and openness, and you've been arguing that openness is by definition a loss of control, and a loss of control threatens a loss of personal rights, ex: open vs. closed source, GPL vs. BSD, and now open vs. closed protocols. It looks like ZDaemon is just not willing to give up some personal freedom for cooperation and openness. I think that's a shame, but your stuff, your rules.

Anyway, enjoy your evening. I'm gonna eat and maybe finally update the rules for the International Doom League. I will end by saying I enjoy our discussions, and I hope you stick around :) .

12-08-12 02:26 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Lyfe said:
The game server should never be told a user's password.

Ever hear of 3-way token authentication for use with 3 possibly unauthorized parties?

12-08-12 02:41 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

dew
Feral Kid

Posts: 2220
Registered: 05-08

Ladna said:
Anyway, enjoy your evening. I'm gonna eat and maybe finally update the rules for the International Doom League.

no rush, man. we wouldn't want to interrupt your important discussion! it's been just a month or two!

12-08-12 03:02 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

@Lyfe
Awe :( its a shame you don't intend to continue the discussion, its been interesting.

GhostlyDeath said:

Ever hear of 3-way token authentication for use with 3 possibly unauthorized parties?

Note that what we are talking about here is a "second" user authentication server independent of the game server (which in this case happens to also be their master). In such an infrastructure you shouldn't pass the user's password to the game server (encoded or otherwise) because it doesn't need to know it. Instead you would hand it the auth token which it can then verify via the authentication server before allowing the client to join.

Last edited by DaniJ on 12-08-12 at 06:26

12-08-12 05:32 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

@Ladna:
So glad you care to be smug.

Regardless, I came here intending to keep a discussion about licensing. (Ok, mostly just to be a smartass about how the GPL locks your code into a license that prevents code-sharing with non-GPL projects. I'm surprised noone called me out on that.)

You all brought up the ZDaemon bullshit. You sit on your little GPL licensed towers, looking down on everyone else because they take a different approach to a problem. We weren't out to make the best open-source doom derivative. We were here to make a fantastic multiplayer doom derivative. We've striven to create a good online experience. Yet obviously this doesn't matter to you since you're banned. So the only thing we have that would matter to you is what we've built. You're not getting it, and you know it, so you try and call us out on any minute detail.

@DaniJ: it's been a slightly interesting theoretical (I use this term since it's not something which will get implemented) discussion. I'm not in any mood to entertain it, since it has lead to a conversation where my only option is to say "that's all fine and dandy, but the ultimate answer is no." To which the pundits here will say "that's because they want control." Just like Apple. Well, fuck yes.

Control of what can connect to your system ultimately leads to an obvious "supported" and "unsupported" set of tools. ZDaemon Launcher - Supported. IDE - Supported. DoomSeeker - not supported. DaniJ's web query tool - not supported. Landa's "fuck you i'm GPL" launcher - not supported. If you need to seriously ask why it's good to have a limited amount of supported 'stuff' (be it hardware, software, etc) - it's simple: It means you have less work to do to make the end result be as polished as possible.

If you want examples: just look at the Android platform versus Apple iOS. You know why most apps come out for iOS first, if not only for iOS? Because it's easy to support. You build it once, according to design, and you can be certain that it will run on all the devices it says it will. Compare that with Android. There's enough horror stories out there, have at it.
You know why Apple doesn't release their OS to the general populace, and requires it to run only on Apple hardware? Because it's easy to support. They build drivers for specific hardware. They build a mouse with only one button, because they can always describe how to do something with a 'click' (as opposed to right/left click).
You know why several popular recent AAA titles don't release modding/map dev tools? Because they don't want to support costs that come with it: eg, running a community with tools questions, building support for random maps into the clients & servers, having to figure out how to get the user-created content from server to client. And most of those AAA titles are based on game engines which have a lot of support for this stuff built in!

So you know why there isn't any desire to add "yet another launcher" to ZDaemon? Because we don't want to have to field the fucking support issues. You know the insinuations. You know the side reasons. Ultimately, more unknown software means more problems. Users are not always the brightest people, and for some reason, the first thing they all want to do is "run a server with this really awesome wad I made in the last 20 minutes."
So if you want to accuse us of control, take the big picture into account, and do it right.

There's more to control than just locking out people who whine and bitch and cause general problems.

And yes, you struck a nerve.

Afterthought:
Since you want to point out problems. Please tell me: How do you combat cheating in your source ports? Or do you just not concern yourself with it, since it's not a technical issue, but rather a player issue?

12-08-12 07:22 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Well, I'm personally happy with that explanation. I might not agree that it is the best way to tackle the problem but its your project and you can rightly do so how you wish.

FWIW, I also thought Ladna's post (and probing of IDE) was in somewhat poor taste given the direction the thread was heading in. Oh well, lets leave it at that. Clearly your skin isn't as thick as the typically-conditioned DW poster...

As for cheating, Doomsday doesn't currently do a great deal to combat it. Basically its limited to stuff like flood protection, well formed protocol negotiation, information denial and validating stuff like player coordinate warping. No doubt we'll expand on this as multiplayer becomes more of a focus for us in the 2.x series.

12-08-12 08:07 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Lyfe said:
You all brought up the ZDaemon bullshit. You sit on your little GPL licensed towers, looking down on everyone else because they take a different approach to a problem. We weren't out to make the best open-source doom derivative. We were here to make a fantastic multiplayer doom derivative. We've striven to create a good online experience. Yet obviously this doesn't matter to you since you're banned. So the only thing we have that would matter to you is what we've built. You're not getting it, and you know it, so you try and call us out on any minute detail.

I can't speak for Ladna, but I personally do not work on Odamex or worked to free the Zandronum source code because I wanted the best source ports to be open source for open source's sake. I did not wake up one morning and say "You know what would be awesome? The best open source doom port."

What I did suddenly wake up and realize is that the community as a whole should have leverage over the administration, not the other way around. Having a source port with a copyleft of some sort just so happens to be aligned with that goal. So if you want to compare apples to apples, try "We were here to make a fantastic community-driven multiplayer doom derivative."

Last edited by AlexMax on 12-08-12 at 15:58

12-08-12 15:47 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 234
Registered: 04-10

Lyfe said:
@Ladna:
So glad you care to be smug.

I'm sorry if I came off as smug, that was my attempt at being magnanimous haha. My bad.

If you think me Wiresharking the launcher stuff was, as DaniJ said, in poor taste, I apologize. I wasn't getting a straight answer from you or phenex2 why you wouldn't support Doomseeker, and you were using the anti-name-faking feature as a reason, and I wanted to see if we couldn't work around that somehow.

Was I wrong in assuming that you wouldn't have told me how it worked if I had asked? By your own admission you don't remember exactly how it worked, yet you still felt comfortable enough saying it precluded supporting Doomseeker. You certainly don't seem eager to try and make changes to it in order to support Doomseeker, so I felt the onus was on me. This is the benefit of community discussion by the way, often times someone solves your problem for you :).

And indeed I do feel that I solved that problem: just have the master generate the auth hash, ez. Or are there other technical reasons you guys can't support Doomseeker?

Lyfe said:

Regardless, I came here intending to keep a discussion about licensing. (Ok, mostly just to be a smartass about how the GPL locks your code into a license that prevents code-sharing with non-GPL projects. I'm surprised noone called me out on that.)

I feel like it's a legitimate debate, and I think you represented the other side pretty well, so I was OK with it.

Lyfe said:

You all brought up the ZDaemon bullshit. You sit on your little GPL licensed towers, looking down on everyone else because they take a different approach to a problem.

Well, really that was just me; in fairness you were acting like source closing never happens, and if it somehow does it isn't really that bad. ZDaemon seemed like a good example, seeing as we were kind of talking around it.

Lyfe said:

Yet obviously this doesn't matter to you since you're banned. So the only thing we have that would matter to you is what we've built. You're not getting it, and you know it, so you try and call us out on any minute detail.

Believe me when I say I have no interest in your community or your software. I just don't want you guys coming around Doomworld, acting like you're good citizens of our community, and shitting on people who actually are good citizens of our community (Blzut3).

I also want to point out that I left the ZDaemon community pretty publicly before I was banned. It was my choice, no one else's.

This line of discussion is kind of a low ad-hominem, and I wish we could avoid it.

Lyfe said:

@DaniJ: it's been a slightly interesting theoretical (I use this term since it's not something which will get implemented) discussion. I'm not in any mood to entertain it, since it has lead to a conversation where my only option is to say "that's all fine and dandy, but the ultimate answer is no." To which the pundits here will say "that's because they want control." Just like Apple. Well, fuck yes.

Rofl, ZDaemon is nothing like Apple. Apple sells more iPads in a day than you guys have users. Let's try and keep the delusions of grandeur to pipe-dream level, we're starting to rise to megalomania here.

Regarding support stuff, just don't support it. Do you think Odamex supports IDE or Doomseeker (well OK, they pretty much help everybody out because they're cool, but they don't have to)? If you're gonna make a "we don't want to waste effort on supporting 3rd-party launchers" argument, along with saying, "we'll spend effort on obfuscating our launcher protocol so 3rd-party launchers aren't even possible", those are conflicting statements. And again, just don't support it.

If you want to make a "polished experience" argument you can make it, but Doomseeker is really, really nice. Just use Wadseeker if you want to be amazed.

Lyfe said:

Afterthought:
Since you want to point out problems. Please tell me: How do you combat cheating in your source ports? Or do you just not concern yourself with it, since it's not a technical issue, but rather a player issue?

No, I think cheating is a concern for any C/S source port. To list the big three:

- Aimbots: statistics, maybe even nudging players 1 pixel this way or that to see if the aimbot switches predictably
- Wallhacks: work out a heuristic for withholding opponent positions if the player can't see them
- Speedhacks: work out a heuristic for limiting player speed (like ZDaemon's, probably)

I get the feeling you're gonna make a "closed source prevents cheating" argument, but that is something you and I both agree is not the case. If it were, we wouldn't need things like Punkbuster, and Valve would never ban anyone, and blah blah blah. It certainly hasn't been the case throughout ZDaemon's closed source history.

Finally, I agree with AlexMax 100%, as usual.

Last edited by Ladna on 12-08-12 at 20:11

12-08-12 20:05 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Dr. Sean
Warming Up

Posts: 14
Registered: 08-11

Ladna said:
Regarding support stuff, just don't support it. Do you think Odamex supports IDE or Doomseeker (well OK, they pretty much help everybody out because they're cool, but they don't have to)?

When I get time to implement new netcode in the near future, I most certainly plan on helping Blzut3 out with implementing it in Doomseeker (or quite possibly taking the burden off him and writing it myself) and the same with IDE. Let's face it: even though I think our own launcher is great, other users have their preferences and it's in our best interest to make sure they can still use Odamex from their launcher of choice.

(Edit: typo)

Last edited by Dr. Sean on 12-08-12 at 20:27

12-08-12 20:17 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 234
Registered: 04-10

Yeah what's funny is I wouldn't even expect Blzut3 to support a port unless they wrote a plugin for him. It just goes to show what a cool guy he is, and overall what a good, collaborative community we have here.

12-08-12 20:44 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

Ladna said:
I'm sorry if I came off as smug, that was my attempt at being magnanimous haha. My bad.

I do not think this word means what you think it means. If it does, you're just being a jerk.

Ladna said:
Rofl, ZDaemon is nothing like Apple. Apple sells more iPads in a day than you guys have users. Let's try and keep the delusions of grandeur to pipe-dream level, we're starting to rise to megalomania here.

Strawman much? Obviously you missed the part about control. Apple likes to control its products. ZDaemon likes to control its resources. Any other implications you think I said are a product of your imagination.

Ladna said:
Or are there other technical reasons you guys can't support Doomseeker?

You're just going to have to live with the answer: "We don't want to."

Ladna said:
No, I think cheating is a concern for any C/S source port. To list the big three:

- Aimbots: statistics, maybe even nudging players 1 pixel this way or that to see if the aimbot switches predictably
- Wallhacks: work out a heuristic for withholding opponent positions if the player can't see them
- Speedhacks: work out a heuristic for limiting player speed (like ZDaemon's, probably)

I get the feeling you're gonna make a "closed source prevents cheating" argument, but that is something you and I both agree is not the case. If it were, we wouldn't need things like Punkbuster, and Valve would never ban anyone, and blah blah blah. It certainly hasn't been the case throughout ZDaemon's closed source history.

Actually, my argument is not that "closed source prevents cheating." You cannot prevent cheating. However, with a closed-source design, the cheaters are fighting an uphill battle just like the anti-cheat. In your open-source design, the cheaters are at a major advantage over any form of anti-cheat, because they can look at whatever crazy methods you're using, and adjust their cheat faster than you can react to it.

Even Carmack acknowledged years ago that you need to have some sort of closed-source anti-cheat. Granted, his design is much more elaborate than what we have in ZDaemon, but we still have a solution in ZDaemon that has been working pretty well.

To get to your suggested solutions:
Aimbots: This strikes me as a completely client-side solution, which.. defeats the purpose in your open-source designs.
Wallhacks:
1- Difficult to implement. There are issues with prediction, edge cases, etc.
2- Because of the issues in (1), you still have to inform clients before they can see the other user, that the other user is approaching, which means your attempt to avoid transmitting needless data will not save someone who reacts quickly.
Speedhacks: Yes, we do some detection. However, SR50 is still a valid speed in the game. But, that doesn't mean you should be able to physically move at SR50 at all times. We found out that this was possible through a macro and removed the ability to do so.

So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.

12-08-12 23:32 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Csonicgo

Posts: 4304
Registered: 03-04

Lyfe said:

So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.

This might come as a shock to you but.. there are only 2 instances of cheating (that I have seen) in odamex, and both have already been fixed. The reason for lack of cheating isn't because of low numbers, but a community that knows each other. Most of the players (if not all) in the IDL are good friends (or aquaintances) with each other and the staff, and as a result, no one cheats in the game because the commmunity is involved with the port.

That's the ticket, here. Skulltag tried the ham-fisted rule approach, which didn't work. Odamex was started with the community in mind, thus there is no bad blood.

When everyone is on an equal level, people aren't pissed off at each other. But as soon as you set up an e-caste system, as in "whatever me says, goes", Well, just look at the ZDaemon page on Encyclopedia Dramatica to see how well that worked, and is working right now.

It's not. It's shit. And you guys know it, and that kills me inside.

The fact that the main staff locked themselves up in a temple just drives that point home.

12-09-12 00:31 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

Csonicgo said:
This might come as a shock to you but.. there are only 2 instances of cheating (that I have seen) in odamex, and both have already been fixed. The reason for lack of cheating isn't because of low numbers, but a community that knows each other. Most of the players (if not all) in the IDL are good friends (or aquaintances) with each other and the staff, and as a result, no one cheats in the game because the commmunity is involved with the port.

You say you have a lack of cheating (due to having a close-knit community), yet you acknowledge knowing about two specific instances of cheats. How have you improved your prevention against further cheating? How do you guarantee that the existing players aren't currently cheating in subtle and non-obvious methods? How do you know that there aren't more cheats that you just haven't been able to detect?

If you are willing to accept the possibility of cheats in your tight-knit community, fine. That's your prerogative. Unfortunately, that does not work for ZDaemon.

The rest of your post is just an unrelated rant about your dislike of ZDaemon's approach to dealing with our unique problem set.

12-09-12 02:13 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Shamash
Newbie

Posts: 8
Registered: 11-12

Csonicgo said:

This might come as a shock to you but.. there are only 2 instances of cheating (that I have seen) in odamex, and both have already been fixed. The reason for lack of cheating isn't because of low numbers, but a community that knows each other. Most of the players (if not all) in the IDL are good friends (or aquaintances) with each other and the staff, and as a result, no one cheats in the game because the commmunity is involved with the port.

That's the ticket, here. Skulltag tried the ham-fisted rule approach, which didn't work. Odamex was started with the community in mind, thus there is no bad blood.

When everyone is on an equal level, people aren't pissed off at each other. But as soon as you set up an e-caste system, as in "whatever me says, goes", Well, just look at the ZDaemon page on Encyclopedia Dramatica to see how well that worked, and is working right now.

It's not. It's shit. And you guys know it, and that kills me inside.

The fact that the main staff locked themselves up in a temple just drives that point home.

Hmm, how can't it be because of the low-number of players? If everybody there knows each other and is friends with each other, then it must mean that there is few players. And if that's the case and there has still been two instances of cheating, then your comment doesn't sound comforting. I couldn't think it possible case if there's really huge number of players, that everybody would be friends with everybody. Most of the players (like me) don't even communicate with the other players in games, but just play it.

I have to ask what you mean with the e-caste system? Isn't it natural that the developers of the program decide what they do with it and the people who spent money on servers, decide what they run on their servers and who can connect to them? At least I would just ignore people who would try to demand and tell how I spent my free time programming and what I do with my own web servers.

12-09-12 02:25 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Shamash said:
Isn't it natural that the developers of the program decide what they do with it and the people who spent money on servers, decide what they run on their servers and who can connect to them?

With ZDaemon, the developers who do not pay server hosts decide who gets to play on servers.

12-09-12 02:48 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Lyfe
Green Marine

Posts: 48
Registered: 11-01

GhostlyDeath said:
With ZDaemon, the developers who do not pay server hosts decide who gets to play on servers.

Only on listed servers. If you want to be listed on ZDaemon, you abide by the ZDaemon global ban list.

12-09-12 02:55 #

Profile || Blog || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Lyfe said:
Even Carmack acknowledged years ago that you need to have some sort of closed-source anti-cheat. Granted, his design is much more elaborate than what we have in ZDaemon, but we still have a solution in ZDaemon that has been working pretty well.

As far as I know, this was actually attempted in both the Quake 1, Quake 2 and Warsow communities. All of them turned out to be trivial to bypass and not worth the trouble to maintain. The "BattleEye" anti-cheat maintainer for Warsow went to work for Bohemia Interactive, which ended up also being hilariously ineffective at combating hacking in Day Z.

Lyfe said:
So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.

Skulltag was closed source for far longer than ZDaemon ever was, and yet towards the later days of 98d I noticed way more cheaters in it than I ever did in ZDaemon's open source days or in Odamex...ever. The opening of Skulltag's source and the release of Zandronum did not seem to bring with it any sort of catastrophic uptick of cheaters either.

You have not 'tackled' cheating. There have been working hacks for ZDaemon ever since the game went closed source, both for 1.07 and 1.08, a period of eight years. If ZDHook hasn't been updated for 1.09, it's more than likely because there simply isn't the demand for a ZDaemon hack anymore, but no matter how you argue it your guys track record is far from spotless.

Perhaps "attempted to tackle" might be better wording on your part. But do you really want to run the risk of being humbled by some bored 15 year old with nothing better to do? Or by a well known player who was cheating discretely for years without you noticing?

Last edited by AlexMax on 12-09-12 at 06:48

12-09-12 06:31 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 20:43.

Pages (12): « First ... « 8 9 10 [11] 12 »

Doomworld Forums > Classic Doom > Source Ports > Source port idea!

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >