Couldn’t find anything about this topic.
I have a Windows TCP C++ server application which I want to update from time to time.
As you obviously understand this introduces a problem – the server should be 24/7 from the users’ perspective.
When updating, it is also desired to keep the current TCP connections with the users.
I’ve been thinking about a module-like system so for example the socket handling module would reside at “sockets.dll”, the server’s logic would reside in “logic.dll”.
Going for this approach seems like opening Pandora’s box;
– How will I make the actual “swapping” of the modules? Imagine that X worker threads keep sending data from one module to another – when swapping I’ll need a (light & fast) way to halt/pause them; signals maybe?
– Protocol version, or even functions signature might change when updating. How to handle that?
– Other problems such as unnoticed logic bugs.
– Who knows kind of other issues will arise.
Besides the above I have concerns like how do I update say 10 servers? I mean, they are all connected to each other, communicating.
If the update introduces a protocol modification it might cause huge problems, and in such case I’ll need to update the whole cluster (of servers) as a whole; shut-down the whole operation? That doesn’t sound right, at all! How do I do that? Which concept(s) am I missing here and how do I learn it/them?
Is there anything I can do about it?
What would you do? Have you done such a thing?
Do you know of any mechanism/article/project/source-example/etc’ that solves the problem?
Any valuable advice is highly appriciated!!
In terms of protocol changes, I recommend you version your protocol. At the beginning of a connection between participating servers, have either the initiator or the receiver (doesn’t really matter which, I think) announce the newest version of the protocol it understands, and then the other side responds in kind. They fall back to the newest version they both understand.
Yes, this means maintaining code for both protocol versions for a while, but you can retire the old code once you know all of your servers are updated and working with the new protocol.
Assuming you have control over all possible client software, as well, you can do the same with your clients. Of course, this may entail maintaining old protocol code longer, if you don’t have control over when users upgrade.