Hello Aaron, On Fri, Oct 18, 2013 at 10:47:53AM -0400, Aaron Boxer wrote: > Hello, > > I would like to build a fast software router for DICOM images. DICOM is a > protocol for medical imaging that runs over TCP. > > The router would receive images and send them to multiple destinations, > using the DICOM protocol. It might also modify part of the image before > sending. > > I was thinking of basing this router on the haproxy code. I know this would > be a lot of work, just wanted to hear opinions on if this makes sense. I am > thinking of haproxy because I admire this project very much.
Some parts might be possible to implement, others not. For example, analysing the protocol on the fly and even fiddling with contents will be possible. You'll have to write your analyser and call it whenever something moves. Just see how HTTP forwarding works in chunked mode, it's exactly the same. However, modifying some of the images might require that you buffer the entire image. I suspect that for such applications you won't have that many concurrent connections and you could easily use extremely large buffers of several megabytes. I don't know if this will be enough of not. The difficult thing will be to send to multiple destinations. Haproxy is *really* not designed for this *at all*. You should see it as a pipe. What enters one side leaves on the other side. And what has been consumed by one side is definitely lost. So I guess that for your case you would have to cut the proxy in two : a server and a client. And for each incoming connection, you'd run as a server, buffering and processing the image (see how stats work), then instanciate a bunch of new sessions, duplicate the buffers and send them to the servers (see how peers work). But then I hope the servers don't need to respond, otherwise it will become complicated (what server response to forward, etc...). As you can see, I'm not convinced it's a good idea to use haproxy for this. You may have more success using products that are really made for servers and clients. And if you don't need particular performance, you'd probably better go with threaded products which will save you from the complexity of dealing with an event-based model. Best regards, Willy
