Repository navigation
Try the plaintext MSSP-REQUEST once per address that never gave option 70 - #198
Merged
Merged
Conversation
…n 70 TelnetNegotiationCore 4.0 ships MSSPPlaintextProtocol, which is what the probe was waiting for. The crawl loop now remembers, per address, how MSSP arrives (crawl_target.mssp_route, migration 0042): - telnet: reported over option 70. Never sent MSSP-REQUEST. Backfilled for every game that already has mssp or mssp_roster fields. - NULL: unknown. After an ordinary session that got no MSSP, the probe makes one short second dial that sends MSSP-REQUEST and nothing else, so a name prompt that turns it into a password prompt never gets the measuring session's WHO typed into it. - plaintext: answered. Asked in-session every crawl, before WHO, so a PLAYERS in the reply spares the game the WHO. - none: did not answer. Never asked again. A plaintext report is stored as mssp like an option-70 one, and is not noted as an option-70 negotiation in the handshake fields. MsspRoutes holds both the ask and the transition, as pure functions. mui-probe gains --mssp-request and --mssp-request=ask for trying it by hand. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YK1nuQCYc9TnnDnWEjcNpS
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing (20)
✨ Finishing Touches📝 Generate docstrings
Comment |
HarryCordewener
marked this pull request as ready for review
October 6, 2026 15:54
HarryCordewener
added a commit
that referenced
this pull request
Oct 7, 2026
…nt (#199) * Refuse an MSSP PLAYERS too large to be an online count Tapestries MUCK answers the plaintext MSSP-REQUEST with PLAYERS = 26842 beside DBSIZE 174343, ROOMS 50509, EXITS 77079 and OBJECTS 19623: the four add to within 290 of the database, so PLAYERS is its player objects. Once #198 started asking, that stated count spared the game its WHO, which had been counting 300 to 500, and the site published 26842 as the number connected. MsspPresence.Stated now refuses a PLAYERS above BannerCount.Implausible, the ceiling the connect-screen rung already uses. The probe and PresenceChoice both read through it, so WHO is asked again and its count is what gets published. ReasonFor no longer calls such a value players_not_numeric: it is a number, and the refusal is ours. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015Ciq6ySnuNyVtkEBnVceLU * Ask WHO where WHO is known to answer, rather than capping PLAYERS Replaces the 10,000 ceiling on MSSP PLAYERS. A stated count is not always the number online, and no threshold tells the two apart: what does is whether WHO works at that address. crawl_target.who_answers_at (migration 0043) records when a WHO typed there last came back counted. WhoAnswers.Learn sets it on a counted WHO and clears it when the login prompt takes WHO for a character name; an unreadable WHO leaves it alone. The crawl loop passes it to the probe as ProbeTarget.WhoAnswers, and where it is set the probe asks WHO even when the game has stated a count. PresenceChoice already ranks WHO above MSSP, so WHO's count is published and MSSP remains the fallback. The migration credits every single-address game with a counted `who` presence row, dated by the newest. Tapestries MUCK is one of them. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015Ciq6ySnuNyVtkEBnVceLU --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by Grave · project thread
Before: the probe never sent the plaintext
MSSP-REQUEST. A game that only serves MSSP that way (the older SMAUG-family form) showed no MSSP at all.After: every address that has never reported over telnet option 70 is asked
MSSP-REQUESTonce. If it answers, its report is stored like any other MSSP report and it is asked again every crawl. If it doesn't, it is never asked again. Addresses that have given MSSP over option 70 are never sent it.The exchange itself is TelnetNegotiationCore 4.0's
MSSPPlaintextProtocol; this PR only decides when to ask and remembers the answer.How
crawl_target.mssp_route(migration 0042):NULLunknown,telnet,plaintext,none. Backfilled totelnetfor every game that already hasmssp/mssp_rosterfields.MsspRoutes.Askmaps the route toProbeTarget.PlaintextMssp(Trial,Ask,Never; defaultNever).MsspRoutes.Learnmaps a probe result to the next route. Option 70 wins from any state. An unanswered trial is final. A former answerer that misses once goes back to unknown for one more trial, so one slow night doesn't drop its only MSSP route.WILL MSSP, the probe dials again, settles the banner, answers pre-screen prompts, sendsMSSP-REQUESTand nothing else. This keeps the measuring session clean: a game that reads the line as a name and moves to a password prompt (the playdecay shape) would otherwise getWHOtyped as a password. The trial can only add to the result; any failure on that dial returns the measurement unchanged.WHO, so aPLAYERSin the reply spares the game theWHOthrough the existingPublishedCountAsyncpath. The reply's side effects land in the discarded slice betweencursors.Bannerandcursors.Flush.MsspTransport.PlaintextRequestand does not addMSSPtoOfferedOptions, socapability.mssp.measuredis not written astruefor a game that never offered option 70.mui-probe --mssp-request(trial) and--mssp-request=ask(in-session) for trying it against a live server by hand.Not measured live: raw TCP to games is blocked from the environment this was built in. Running
mui-probe <host> <port> --mssp-requestagainstcoffeemud.net 2327or a SMAUG game would be a good check before merge.Tests:
PlaintextMsspTests(fake servers: plaintext-only answerer, name-reader with a password prompt, hang-up on unknown name, option-70 server),MsspRoutesTests,MsspRoutePostgresTests. Crawl 613, Discovery 361, Crawler 363 pass locally against Postgres.🤖 Generated with Claude Code
https://claude.ai/code/session_01YK1nuQCYc9TnnDnWEjcNpS
Generated by Claude Code
Summary by CodeRabbit