Le 13/01/2014 14:56, Martin Sustrik a écrit :
Sure, but it is anyway necessary and desirable in my client application. Typically, the whole server is stateless, but it is cheaper that a client remains with the same server. So I will assign to each client a default server and different fallbacks. For example, say I have two servers only, half of my clients will default to server A and fallback on server B, and the other half will default to B and fallback to A. Clients have just to manage a delay for a valid response. I have to check, but I think I can use in-the-box nanomsg features for that. On the other hand, inside a server, the workers are statefull.The problem with statefull req/rep is how to handle partial failure. If one worker dies, some clients will be stuck forever. You have to define a mechanism for recovering from such problems.
Statefull and Stateless are different paradyms with each their own advantages, drawbacks and constraints. Each one is the right one for some problems.
Like Drew Crawford explained it in details in his December 2013 posts, statefull is right for security handchecks. You can always convert a statefull design in a stateless one, but sometimes you prefer the statefull one for cost, performance and complexity reasons. That's why I am preaching for plumbing functions that open nanomsg API, and possibly in the future statefull protocols and/or devices.
