lukeaschenbrenner
commented
1 month ago Hi, thanks for taking the time to leave feedback for the app. I agree that adding aspects of TCP to this protocol like sequence numbers and a checksum would be massively useful to make this app more feasible. However, if I am considering that, it might make more sense to develop a separate more general-purpose communication library over SMS that could be implemented as, for example, a TCP proxy. As the protocol exists right now, we actually do have sequence numbers in each message using the first two characters (with a maximum HTML transmission capping at ~13,000 SMS messages). The real issue here is knowing when the carrier has actually dropped the message vs if the message is severely delayed, which is possible. Delayed server response SMS messages are actually a huge issue because they can insert themselves into the response for a future request by accident, invalidating the brotli bytecode response and failing to decode. IMO, a checksum for the entire contents are not needed at the moment because the entire data integrity needs to be maintained to succeed at decoding. If a decode failed, we have no way of knowing which message was invalid. Only way I could see getting out of this is by adding a unique ID to each request, which would waste valuable space in each response!
Hi!
I was reading the readme file and saw the following issue: "In congested networks, it's possible for a mobile carrier to drop one or more SMS messages before they are recieved by the client. Currently, the app has no logic to mitigate this issue, so any websites that have stalled for a significant amount of time should be requested again."
It then occurred to me that it was possible to fix it with TCP-like headers, specifically the Sequence Number. While we are at it, other aspects of this protocol could be implemented as well, such as the Checksum.
Thank you for your time and I hope I helped, DarthWynaut.