On Thu, Aug 18, 2011 at 5:54 PM, Bob Ippolito <span dir="ltr"><<a href="mailto:bob@redivi.com">bob@redivi.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Thu, Aug 18, 2011 at 8:48 AM, Magnus Klaar <<a href="mailto:magnus.klaar@gmail.com">magnus.klaar@gmail.com</a>> wrote:<br>
> 2011/8/18 ori brost <<a href="mailto:oribrost@gmail.com">oribrost@gmail.com</a>><br>
>><br>
>> I will describe my exact problem, maybe there are other solutions i<br>
>> did not think of.<br>
>> Our program provides a websocket service over a port. We wish to allow<br>
>> people without a websocket supporting browser to use it so we use a<br>
>> flash object to do websocket when the browser can't. In order for this<br>
>> to work, the flash object needs to get a flash policy file. Flash<br>
>> forces the file to be in one of two places:<br>
>> - port 843 (flash hard coded)<br>
>> - the port of the ws service<br>
>> Note that the flash protocol is NOT HTTP based.<br>
>> Originally we worked with 843, but we then decided to put out server<br>
>> behind an Amazon ELB. Amazon ELB does not allow port forwarding for<br>
>> ports below 1024 which are not 80 or 443, so our only choice was to<br>
>> implement the flash policy file server in the same port via a patch to<br>
>> mochiweb (<a href="https://github.com/nivertech/mochiweb/tree/ori_flash_170811" target="_blank">https://github.com/nivertech/mochiweb/tree/ori_flash_170811</a>).<br>
>> We also thought of putting the websocket service behind an haproxy<br>
>> instead of ELB, but ELB is better because it is also hardware based<br>
>> unlike haproxy which is only software.<br>
>><br>
>> Do you see any other solution for this?<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
> Hi!<br>
> This is a shameless plug for cowboy, putting this aside, I think it you<br>
> would end up with a solution similar to this if you were to patch mochiweb<br>
> suit this usecase.<br>
> I wrote a blog post on getting started using cowboy for non-http protocols<br>
> yesterday because of a question on IRC wrt. to finding a reusable<br>
> acceptor/handler pool for connection oriented servers. You will find it<br>
> here: <a href="http://mklaar.posterous.com/accepting-and-handling-tcp-connections-with-c" target="_blank">http://mklaar.posterous.com/accepting-and-handling-tcp-connections-with-c</a><br>
> Now, you would be able to write a protocol module such as<br>
> flash_policy_or_http_protocol that read N bytes from the socket, if they<br>
> match an HTTP method, you can call the cowboy_http_protocol:init/4 and<br>
> handle it as an HTTP request. If they match what you expect to find at the<br>
> head of a flash policy request you can call flash_policy_protocol:init/4.<br>
> The only change I anticipate that you would have to make to cowboy itself<br>
> would be to add an option for injecting an intial buffer into the<br>
> cowboy_http_protocol state to ensure that erlang_decode:packet doesn't start<br>
> reading in the middle of the input.<br>
> (I failed at the internet, I'm sorry if you receive duplicates of this<br>
> email)<br>
<br>
</div></div>FWIW, mochiweb also has a reusable acceptor/handler pool<br>
implementation with an unsurprising name: mochiweb_socket_server.<br>
mochiweb_http is just a handler that sits on top of this facility.<br>
<br>
In either case, if you need to stuff something back onto the socket<br>
buffer, there's an undocumented gen_tcp:unrecv/2 that would work if<br>
you can't find an elegant and supported way to do it.<br>
<font color="#888888"><br>
-bob<br>
</font></blockquote></div><br><div>Hi!</div><div><br></div><div>Nice, that solves this problem then. I only took a quick look at mochiweb_socket_server and mochiweb_http, but it looks like there is nothing stopping you from using the same module structure as I suggested earlier. Replace Protocol:init/2 in my post with Protocol:loop/2 and you're done.</div>
<div><br></div><div>Making changes to either one of the flash_policy or mochiweb-http module will land you with at least one module that is "bloated" or hard to reuse.</div><div><br></div><div>MVH Magnus Klaar</div>