[erlang-questions] gen_tcp send blocks gen_tcp recv.

[Arun Muralidharan]

Hi Satyam,
I think you are probably using a flawed term in describing your
application' "performance" issue.
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.

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.


-Arun


On Tue, Sep 4, 2012 at 1:37 PM, Joseph Wayne Norton <
norton@REDACTED> wrote:

>
> Satyam -
>
> The UBF framework may offer some examples for building a server, client,
> and protocol driver:
>
> generic socket server:
>     https://github.com/ubf/ubf/blob/master/src/proc_socket_server.erl
>
> generic protocol driver:
>     https://github.com/ubf/ubf/blob/master/src/contract_driver.erl
>
> There is some documentation that describes how the framework works at a
> high-level:
>    http://ubf.github.com/ubf/ubf-user-guide.en.html
>
> Hope this helps.
>
> - Joe N.
>
> On Sep 4, 2012, at 4:45 PM, Satyam Shekhar <satyamshekhar@REDACTED>
> wrote:
>
> @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?
>
> @arun: The article on trapexit only show how to do async accept. It doesnt
> do async send of gen_tcp socket.
> 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.
>
> How do people usually handle such scenarios?
>
>
> On Mon, Sep 3, 2012 at 9:01 PM, Arun Muralidharan <arun11299@REDACTED>wrote:
>
>> 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.
>> Why dont you try an async design pattern as shown in
>>
>> http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles
>>
>> -Arun
>>
>>
>>
>> On Mon, Sep 3, 2012 at 12:47 PM, Erik Søe Sørensen <eriksoe@REDACTED>wrote:
>>
>>> Have you considered having one process for sending and one for receiving
>>> (on the same socket)?
>>> Den 03/09/2012 06.47 skrev "Satyam Shekhar" <satyamshekhar@REDACTED>:
>>>
>>>>  Hi,
>>>>
>>>> I know this question has been asked many times.
>>>>
>>>>
>>>> http://erlang.2086793.n4.nabble.com/Non-blocking-sends-in-gen-tcp-td2114537.html
>>>>
>>>> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/4DBmCK4GAK8
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> What is the best way to handle this?
>>>>
>>>> Regards,
>>>> Satyam Shekhar
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120904/a63fe0dd/attachment.htm>