Each problem defines a network protocol for you to implement. You run the server, we'll run the client, and we'll check whether your server works.
It is intended that the protocols (other than the Smoke Test) will require at least some custom programming. For example, if I wanted to make a problem related to HTTP, I might modify the protocol so that it can't simply be solved by running nginx.
Yes. You can do so using any method that is convenient to you, including hosting it on your home Internet connection or using a cloud VPS.
I don't mind what you use for connectivity, but note that ngrok in particular seems to close the connection entirely as soon as it sees a half-duplex shutdown. This makes it impossible to solve the Smoke Test using ngrok.
(Yes, but it might not work. Give it a go, and if it doesn't work please get in touch and we can try and solve it together).
Any language you like.
Yep, although it's fine to set your own personal restrictions on what you allow yourself to use. Do whatever you prefer.
The expected solution is that you'll write the program in whatever way you feel most natural in whatever environment you happen to be using. You don't need to feel as if you've "cheated" just because you haven't implemented TCP yourself.
You're certainly welcome to implement TCP yourself if you want to, and I'd be interested in seeing this! But I don't expect most to attempt it.
Enable "Receive emails about Protohackers" in your profile settings.
If you don't want to do that, you can consult the "Next problem" countdown on the home page and make a note in your calendar or similar.
The first ones are meant to be easy. Not everyone writes network servers all the time.
If you think too many of the problems are too easy, that would be useful for me to know, so please let me know.
If you need help with a specific problem, see the help page. Break the problem down into smaller parts, solve the smaller parts, put them together into a complete solution. You can do it. I believe in you.
If you think too many of the problems are too hard, that would be useful for me to know, so please let me know.
If the problem statement doesn't mention it, then it shouldn't matter what you do, because the checker shouldn't be doing anything that isn't covered by the protocol specification in the problem statement.
If you think the checker is relying on some behaviour that is not explicitly prescribed in the problem statement, then that sounds like a bug in the problem statement, so please email me to let me know.
Mmm. Sorry. That hadn't occurred to me. The checker is hosted at DigitalOcean in London, so if you want a lower-latency connection to the checker, maybe consider hosting your server in London.
If this is actually a problem for you, please email me and we'll do something about it. I expect either increase the check timeout, or change the check so that it doesn't have to wait for so many round trips.
A cuckoo lays its eggs in other birds' nests.
Cuckooing in Protohackers is "solving" problems by giving the IP address and port number of a different user, to piggyback on the solution that the other user has implemented.
For now, nothing.
If it actually becomes a problem, then the solution would be along the lines of assigning each user some sort of UUID, and querying the UUID as part of the protocol, so that Alice's server will fail on checks initiated by Bob, because it will provide Alice's UUID instead of Bob's.
Yes, but there is no documentation and I might change it at any time with no warning.
Try not to overload the server. If convenient, put some contact information in the User-Agent, so that if your program goes haywire I know who to speak to.
See our policy on vulnerabilities.
The short answer is you are allowed to exploit a vulnerability to cheat on 1 problem, but don't do anything that might upset anyone. After you've exploited it once, tell me so I can fix it.
This is definitely something I'd consider adding. Please email me to let me know you have this preference.
Great! Please send it to me. I might not use it, but I'll stick it in my text file of cool problem ideas.
Maybe! Email me and let's talk.
Send electronic mail to email@example.com.
Looking forward to hearing from you.