Sounds like you really know your networking. Really appreciate your thoughts here.
We can’t get into too much detail on carrier stuff but in some cases we have control over those timeouts and in some cases we don’t depending on our agreements and relationships.
We’re going down similar lines of thought as you and are experimenting with different protocols to see what would work well here. Some sort of UDP-based custom protocol that took certain concepts from TCP in order to acknowledge delivery would be a good way to save data while preventing lost messages but it might be a little while before we have that fully fleshed out.
Reply is actually not required right now so if you close the connection immediately after sending it should still go through (depending on things being buffered by the OS) and you may not have to incur any bytes on the response. It’s very timing dependent though and we’ve seen on some devices that it’s a coin flip on whether it actually sends the message or not.
Heh, good point. I didn’t mean to come across as that confident as nothing like that is really impossible. The main advantage from this architecture on the security side is that an attacker doesn’t know if he actually found the right key or not and really would have no idea if his message made it into a customer’s account unless he had access to the account itself at which point this is moot. This makes it incredibly difficult to try to inject invalid data into someone’s account as you never really know what their key is.
That being said, we realize that this isn’t great feedback for customers either and are doing some reevaluation around here about whether we want to make changes to our architecture to provide that authentication response. It’s a slightly bigger change because there’s actually a physical separation between that TCP endpoint service and our actual cloud service that does the authentication and routing.