Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove: COMPANY_INFO packets and related code #9475

Merged
merged 1 commit into from Aug 14, 2021

Conversation

TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Aug 14, 2021

Motivation / Problem

#9467 asked if we could remove the COMPANY_INFO packets, as they are now unused (by our clients).

Description

To get a bit of visual what it involves, I created this PR. I have several reservations whether this is a good idea or not.

  • This also removes any other (custom) client to get company info. But to counter that, Suggestion: Option not to disclose server information when password-protected #7268 has a good point that showing company info on a private server is a bit weird .. and not really what you expect in 2021. So removing this would also work towards resolving Suggestion: Option not to disclose server information when password-protected #7268.
  • COMPANY_INFO is part of the DO NOT CHANGE THIS .. which makes me wonder if there is anything I am overlooking, why this would be bad. I noticed I failed to estimate the impact of this.
  • Currently you can gather this information from every server in the public listing. That might not have been the intention of this packet, but this removes that ability. It has to be noted that the admin port still has the ability to get the company info, but this of course requires authorization.
  • Servers might use this on a banner to show who is on their server, how many trains, etc. They really should be using the admin port for that, but one cannot guarantee someone is using this.

We can also do everything "in between". Only remove the client-side, only remove the server-side, leave it alone.

I am rather conflicted about this, but I just present this PR so we can have a talk.

Edit: the more I think about it, the more I think all cases I mention where people might be using this packet, are illegal use of the packet. Additionally, #7268 really points out this packet should not exist in this form. So I do think we should remove it. Means we can also safely close #7268, as with this PR (combined with all the other work done on multiplayer) it is sufficiently addressed in my opinion.

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

Copy link
Member

@LordAro LordAro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shrug.

@TrueBrain TrueBrain merged commit 1ef4d3c into OpenTTD:master Aug 14, 2021
@TrueBrain TrueBrain deleted the remove-company-info branch August 14, 2021 21:24
@YorVeX
Copy link

YorVeX commented Nov 25, 2021

Is it intended that now the response to a PACKET_UDP_CLIENT_FIND_SERVER request is an empty packet of type PACKET_UDP_SERVER_RESPONSE with the packet version field also defaulting to 0, making all clients which had previously implemented parsing that response now think they are getting an outdated packet version? To me it was really confusing. So I think this code in network_udp.cpp is just a leftover and should be removed:
image

I don't see the point in sending an empty response (with an "older" packet version than in previous implementation), just don't respond to that packet at all if you don't want people to be able to get this information anymore through a public UDP request.

Though I don't really understand what the problem with it was in the first place or why it would have been "illegal" use, there is so many game server implementations including big ones like Half-Life/Source engine that give back basic server data in UDP responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Suggestion: Option not to disclose server information when password-protected
4 participants