+Al_Nafuur Posted August 31, 2021 Share Posted August 31, 2021 Currently, the PlusROM functions use the HTTP header "PlusStore-ID" for their requests to their backends. This header should actually only be used for the communication of the PlusCarts with the PlusStore. Since emulators should also communicate with the PlusROM backends (but not with the PlusStore!), a different header should be used for PlusROM communication. The information to be transmitted to the PlusROM backend with this header field is: device type (0 = Unknown, 1= PlusCart, 2 = Gopher2600, 3 = Javatari.js, 4 = Stella, ..). version unique device ID nickname (this is not necessarily a unique username) My suggestion is to use the HTTP header "PlusROM-Info". And separate the data with a "|". e.g. PlusROM-Info: 1|v2.1.1|0123456789ABCDEF0123456789ABCDEF|Al_Nafuur However, because there are already some devices and emulators that still send their data to the PlusROM backends according to the previous standard, the backends must be able to distinguish between the two versions. any thoughts or suggestions @JetSetIlly, @DirtyHairy, @Thomas Jentzsch, @Andrew Davie or anyone else? Link to comment Share on other sites More sharing options...
DirtyHairy Posted August 31, 2021 Share Posted August 31, 2021 (edited) Suggestions: Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table Use an UUID for the random ID, that's a standard, and there are packages to generate them Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier My suggestion would look like this: PlusROM-Info: platform=Stella 6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy Edited August 31, 2021 by DirtyHairy 1 Link to comment Share on other sites More sharing options...
JetSetIlly Posted August 31, 2021 Share Posted August 31, 2021 18 minutes ago, DirtyHairy said: Suggestions: Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table Use an UUID for the random ID, that's a standard, and there are packages to generate them Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier My suggestion would look like this: PlusROM-Info: platform=Stella 6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field. 2 Link to comment Share on other sites More sharing options...
DirtyHairy Posted August 31, 2021 Share Posted August 31, 2021 (edited) 7 minutes ago, JetSetIlly said: I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field. On third thought, I agree ? To put this into code PlusROM-Info: platform=Stella; platform-version=6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy Edited August 31, 2021 by DirtyHairy Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 31, 2021 Author Share Posted August 31, 2021 2 hours ago, DirtyHairy said: Suggestions: Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table 2 hours ago, JetSetIlly said: I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field. ? 2 hours ago, DirtyHairy said: Use an UUID for the random ID, that's a standard, and there are packages to generate them I thought of using GUID/UUIDs too, but without the unnecessary hyphens. 2 hours ago, DirtyHairy said: Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches ? except for the 32 chars I think 16 should be enough for a nick. And maybe add [_] too, otherwise my nick would be invalid ? 2 hours ago, DirtyHairy said: I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier I am a great fan of using existing standards too. 2 hours ago, DirtyHairy said: On third thought, I agree ? To put this into code PlusROM-Info: platform=Stella; platform-version=6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy This looks nice and is human readable (even if it doesn't need to be). But there is one more thing I would like to mention. Using tcp and http in "gaming" is already a disadvantage, so I want to keep these requests as small as possible to minimize tcp packages and to stay way below the standard MTU size of 1500 bytes (1460 or 1448 bytes payload). Some network connections can have smaller MTU sizes. The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things: PlusROM-Info: agent=Stella; ver=6.4.1; id=0123456789ABCDEF0123456789ABCDEF; nick=Al_Nafuur Link to comment Share on other sites More sharing options...
JetSetIlly Posted August 31, 2021 Share Posted August 31, 2021 5 minutes ago, Al_Nafuur said: The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things: PlusROM-Info: agent=Stella; ver=6.4.1; id=0123456789ABCDEF0123456789ABCDEF; nick=Al_Nafuur I like that. Link to comment Share on other sites More sharing options...
DirtyHairy Posted August 31, 2021 Share Posted August 31, 2021 (edited) 28 minutes ago, Al_Nafuur said: The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things: Why? To me that sounds like unnecessary optimization. If the packet fragments, so what? Besides, the request size will still be way below the MTU. Using an ESP connected via serial to an Atari 2600 already excludes high performance communication ? EDIT: Besides, now that I rethink this, an HTTP request larger than the MTU will not usually cause fragmentation at the IP level. Instead, afaik,socket transmissions that exceed the MTU will be split by the network stack into multiple IP packets that fit the lowest MTU on the path. Edited August 31, 2021 by DirtyHairy Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 31, 2021 Share Posted August 31, 2021 9 hours ago, DirtyHairy said: [0-9a-zA-Z ]{0,32} IMO we should require a minimum length (2 or 3). A few more chars (if feasible) would be nice. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 1, 2021 Author Share Posted September 1, 2021 On 8/31/2021 at 10:31 PM, Thomas Jentzsch said: IMO we should require a minimum length (2 or 3). A few more chars (if feasible) would be nice. Some users may not want to be "registered". Also there are currently 55% of the PlusCarts not connected to a PlusStore account and so their PlusStore-Id cannot be resolved to a username Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 2, 2021 Share Posted September 2, 2021 Ok, but if they decide to register, IMO a minimum length should be enforced. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 2, 2021 Author Share Posted September 2, 2021 1 hour ago, Thomas Jentzsch said: Ok, but if they decide to register, IMO a minimum length should be enforced. The minimum length for a username in nextcloud is 1 char. So a PlusCart that is connected to a PlusStore account will send at least 1 char. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 2, 2021 Share Posted September 2, 2021 That should be the rule for emulators then too, IMO. Link to comment Share on other sites More sharing options...
DirtyHairy Posted September 2, 2021 Share Posted September 2, 2021 Just don't include the nick field if someone has not registered. Otherwise, let's take the 1 char minimum then. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 2, 2021 Share Posted September 2, 2021 Hm, you mean we should submit scores without registration? @Al_Nafuur what do you think? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 2, 2021 Author Share Posted September 2, 2021 18 minutes ago, Thomas Jentzsch said: Hm, you mean we should submit scores without registration? @Al_Nafuur what do you think? That's what we are already doing. At the PlusROM High Score Club these emulator accounts or PlusCarts are listed as "unknown Emulator user xyz" and "unknown PlusCart user xyz". The numbers are determine by the PlusCart device id, if the device id cannot be resolved via the open API. For Emulators these number is determined by the device id and nickname. Emulator nicknames are not unique (unlike PlusStore usernames), so they are listed with a number determined by the device id too. E.g. "Al_Nafuur emulator user 17" is my firefox javatari.js account "Al_Nafuur emulator user 120" is my gopher2600 installation account. How these numbers and entries are generated from the device id and/or nickname (if given) is totally up to the PlusROM backends. The C.A.V.E. Apocalypse backend does not generates any user names. You just need to connect your emulator device id (or PlusCart device hash) with your C.A.V.E. Apocalypse Level Editor account to play your private levels. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 3, 2021 Share Posted September 3, 2021 OK, got you. Link to comment Share on other sites More sharing options...
DirtyHairy Posted September 7, 2021 Share Posted September 7, 2021 @Al_Nafuur Are you going to switch? We are currently finalizing Pluscart support in Stella, and I wonder whether I keep the old header or send new one ? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 7, 2021 Author Share Posted September 7, 2021 Either way, the PlusROM backends must be able to understand old and new headers. So if we can agree on one variant for the new header, I could add the new header to the backends I host (as far as I know, no one has created their own PlusROM with a backend yet). Link to comment Share on other sites More sharing options...
JetSetIlly Posted September 7, 2021 Share Posted September 7, 2021 2 minutes ago, Al_Nafuur said: Either way, the PlusROM backends must be able to understand old and new headers. So if we can agree on one variant for the new header, I could add the new header to the backends I host (as far as I know, no one has created their own PlusROM with a backend yet). I think your most recent suggestion is fine. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 7, 2021 Author Share Posted September 7, 2021 1 minute ago, JetSetIlly said: I think your most recent suggestion is fine. There is one more thing I stumbled across when I starred at some of the backends. The Browser based emulators need a CORS header, so the browser won't ignore/hide the response from the application. Currently the backends can determined this by the "WE" prefix of the generated device-id. With our new header they would have to determine this by the "agent" string. Link to comment Share on other sites More sharing options...
DirtyHairy Posted September 7, 2021 Share Posted September 7, 2021 (edited) 2 hours ago, Al_Nafuur said: There is one more thing I stumbled across when I starred at some of the backends. The Browser based emulators need a CORS header, so the browser won't ignore/hide the response from the application. Currently the backends can determined this by the "WE" prefix of the generated device-id. With our new header they would have to determine this by the "agent" string. Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it. However, you are doing POST with a custom header, and I would expect that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header). You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it. Edited September 7, 2021 by DirtyHairy Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 8, 2021 Author Share Posted September 8, 2021 1 hour ago, DirtyHairy said: Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it. ? 1 hour ago, DirtyHairy said: However, you are doing POST with a custom header, and I would expect that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header). Yes right, (but the preflight requests are sent from the browser) 1 hour ago, DirtyHairy said: You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it. most of the PlusROM backends i have built so far were actually only meant as PoC and don't use any special web framworks.. I will start tomorrow to extend these to the new headers and will give feedback here. Link to comment Share on other sites More sharing options...
DirtyHairy Posted September 8, 2021 Share Posted September 8, 2021 5 hours ago, Al_Nafuur said: Yes right, (but the preflight requests are sent from the browser) Ups, sorry, typo, "browser" is what I wanted to write ? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 8, 2021 Author Share Posted September 8, 2021 19 hours ago, Al_Nafuur said: most of the PlusROM backends i have built so far were actually only meant as PoC and don't use any special web framworks.. I will start tomorrow to extend these to the new headers and will give feedback here. The backends of the following PlusROMs should now work with the new header too: all High-Score-Club games PlusClock bB-painter bB-maps online combat t-online newsticker ( this backend doesn't work currently because of a bug in the news API) these PlusROM backends still have to be extended: C.A.V.E. Apocalypse Sokoboo Plus Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 10, 2021 Author Share Posted September 10, 2021 The C.A.V.E. Apocalypse backend is now adapted to cope with the new headers too. Link to comment Share on other sites More sharing options...
Recommended Posts