To answer you both I must clarify that I do not plan to invent the wheel. I was thinking about WCCP at first and I learned it some time ago but.. It's far easier to wrote a daemon that *will not* be a part of squid code that will notify to the router daemon about squid state and existence. I will not try to bother squid developers to try and add support embedded into squid for such a task.
The idea is: 2 different daemons First the squid or another software side which will have some "marker" or a "flag" for the squid proxy state. This daemon will verify if squid or anther proxy is indeed running fine. Also there is an option for a third side status reflector that will help to monitor the proxy state else then the daemon that sits on the proxy. Second a daemon on the router which will do all sort of weird things like IPTABLES and IP rules that will make sure that the traffic is being routed to the right proxy and will get to a decision based on the "third wheel and it own monitoring". I will not write and RFC since I really don't want to and I think that when and if implemented it would be very simple to operate. So just announcing and nothing else. If the project would like the concept and the idea and someone will want to use this idea and software he can feel free to... it will probably be a 3 clause BSD licensed software. All The Bests, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: [email protected] -----Original Message----- From: Alex Rousskov [mailto:[email protected]] Sent: Sunday, April 2, 2017 8:22 PM To: [email protected] Cc: Eliezer Croitoru <[email protected]> Subject: Re: [squid-dev] [RFC] WCCP alternatives implentations. On 04/02/2017 03:40 AM, Eliezer Croitoru wrote: > I am planning to write a daemon for Linux routers that will be the > alternative to WCCP on Linux or other routers. > I am not going the 100% binary format like WCCP but a more HTTP\RPC a > like protocol. FYI: The latest HTTP version is "100% binary". > So first, would the squid project like to cooperate with such a feature? If somebody submits a high-quality patch adding support for an experimental peering protocol, it will be reviewed and might be accepted, but designing and implementing a new protocol is a very difficult task, and there are bigger Squid problems to solve than WCCP improvements, so I would discourage spending scarce Project resources in this direction (and risking rejection). > I want to know if there are some recommendations and guidelines before > implementing such a project. If you are sure a new protocol is needed, then I recommend starting with an Internet Draft and getting that peer reviewed by interested parties (which you will need to find!). Garri has offered good starting points for this kind of work in his response to your RFC. None of these first steps require Squid development or even Project participation. After that, you can come back to squid-dev with a reviewed Draft and try to secure "acceptance in principle" in advance of a Squid implementation. The next step would be to find a developer willing to implement your Draft specs in Squid. You can make this your first step, but doing so may be impractical without more detailed specs (at least). HTH, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
