Hi Satyam,<div>I think you are probably using a flawed term in describing your application' "performance" issue.</div><div>In most of the cases unlike "blocking recv" , send function is fast meaning it wont take much time to copy the data from application to kernel buffer unless there is low memory in kernel buffer to copy your data or due to some page fault.</div>
<div><br></div><div>But what can really be a problem is when your process is processing the received data from socket slowly. For this you have to decouple the logic of receiving and processing. For eg. a single erlang process for receiving events (maybe a gen_server or gen_fsm) and for each received data spawn a new process that acts on it and sends it.</div>
<div><br></div>
<div><br clear="all">-Arun<br>
<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 1:37 PM, Joseph Wayne Norton <span dir="ltr"><<a href="mailto:norton@lovely.email.ne.jp" target="_blank">norton@lovely.email.ne.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div>Satyam -</div><div><br></div><div>The UBF framework may offer some examples for building a server, client, and protocol driver:</div><div><br></div><div>generic socket server:</div>
<div> <a href="https://github.com/ubf/ubf/blob/master/src/proc_socket_server.erl" target="_blank">https://github.com/ubf/ubf/blob/master/src/proc_socket_server.erl</a></div><div><br></div><div>generic protocol driver:</div>
<div> <a href="https://github.com/ubf/ubf/blob/master/src/contract_driver.erl" target="_blank">https://github.com/ubf/ubf/blob/master/src/contract_driver.erl</a></div><div><br></div><div>There is some documentation that describes how the framework works at a high-level:</div>
<div> <a href="http://ubf.github.com/ubf/ubf-user-guide.en.html" target="_blank">http://ubf.github.com/ubf/ubf-user-guide.en.html</a></div><div><br></div><div>Hope this helps.</div><div><br></div><div>- Joe N.</div><div>
<div><br><div><div>On Sep 4, 2012, at 4:45 PM, Satyam Shekhar <<a href="mailto:satyamshekhar@gmail.com" target="_blank">satyamshekhar@gmail.com</a>> wrote:</div><br><blockquote type="cite">@erik: I wasn't sure if this was the standard practice. Also, this complicates the architecture. Now, I ll have 2 processes, that manage a tcp socket. One for receiving and one for sending, both having reference to the same socket. Is this ok?<div>
<br></div><div>@arun: The article on trapexit only show how to do async accept. It doesnt do async send of gen_tcp socket. </div><div>To elaborate on the problem - I have one process that is an abstraction over the gen_tcp socket. It does xml parsing on the data received on the tcp socket and forwards parsed data to the controlling process. Also it receives the xml from a process and sends it on the tcp socket. Lets call this smart socket. Now, if the process that sends data to smart socket, sends too much of it, smart socket starts to starts blocking on send calls.</div>
<div><br></div><div>How do people usually handle such scenarios?</div><div><div><br></div><div><br><div class="gmail_quote">On Mon, Sep 3, 2012 at 9:01 PM, Arun Muralidharan <span dir="ltr"><<a href="mailto:arun11299@gmail.com" target="_blank">arun11299@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can you be more specific on how your sending process is overloading your receiving process(P1) by making a "blocking" call ? I didnt quite get it. <div>
Why dont you try an async design pattern as shown in </div><div>
<a href="http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles" target="_blank">http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles</a> <span><font color="#888888"><br clear="all">
-Arun</font></span><div><div><br>
<br><br><div class="gmail_quote">On Mon, Sep 3, 2012 at 12:47 PM, Erik Søe Sørensen <span dir="ltr"><<a href="mailto:eriksoe@gmail.com" target="_blank">eriksoe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Have you considered having one process for sending and one for receiving (on the same socket)?</p>
<div class="gmail_quote">Den 03/09/2012 06.47 skrev "Satyam Shekhar" <<a href="mailto:satyamshekhar@gmail.com" target="_blank">satyamshekhar@gmail.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Hi,<div><br></div><div>I know this question has been asked many times. </div><div><br></div><div><a href="http://erlang.2086793.n4.nabble.com/Non-blocking-sends-in-gen-tcp-td2114537.html" target="_blank">http://erlang.2086793.n4.nabble.com/Non-blocking-sends-in-gen-tcp-td2114537.html</a></div>
<div><a href="https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/4DBmCK4GAK8" target="_blank">https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/4DBmCK4GAK8</a></div><div><br></div>
<div>But my concern is slightly different. I have a separate sending/receiving process, P1, for a gen_tcp socket which receives messages it has to send, from process P2. There is no acking between the P1 and P2. Data is buffered at P2 and data acking is client driven, i.e that client says how much data it has received when it reconnects. Right now, P2 sends data to P1 as soon as it generates any data, and also adds it to its buffer, so that it can send it to the client if the socket gets closed before client receives it.</div>
<div><br></div><div>The issue is, since the gen_tcp send call is blocking, and P2 might flood P1s mailbox at times, received messages(socket in active once mode) from the client are delayed quite a bit.</div><div><br></div>
<div>What is the best way to handle this?</div><div><br></div><div>Regards,</div><div>Satyam Shekhar</div>
<br></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></blockquote></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">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>
</blockquote></div><br></div></div></div></blockquote></div><br></div>