[erlang-questions] erlang-questions Digest, Vol 23, Issue 29
Gamoto
gamoto@REDACTED
Thu Apr 9 11:00:33 CEST 2009
Hi Steve,
Yes: RTFM as say Linux people.
But it is not my mentality. If I don't down then I ask. If I know then I share.
Have a good day !
John
>Send erlang-questions mailing list submissions to
> erlang-questions@REDACTED
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://www.erlang.org/mailman/listinfo/erlang-questions
>or, via email, send a message with subject or body 'help' to
> erlang-questions-request@REDACTED
>
>You can reach the person managing the list at
> erlang-questions-owner@REDACTED
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of erlang-questions digest..."
>
>
>Today's Topics:
>
> 1. Re: checksum calculation (Steve Davis)
> 2. Re: strange behaviour of gen_tcp:connect (Oscar Hellstr?m)
> 3. tcp_send_error (Anthony Shipman)
> 4. Erlang on Emacs (sameer pradhan)
> 5. Re: strange behaviour of gen_tcp:connect (Gamoto)
> 6. Re: : strange behaviour of gen_tcp:connect (Raimo Niskanen)
> 7. Re: tcp_send_error (Sverker Eriksson)
> 8. Re: State of the Union: FFI (Franco Milicchio)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 8 Apr 2009 04:04:26 -0700 (PDT)
>From: Steve Davis <steven.charles.davis@REDACTED>
>Subject: Re: [erlang-questions] checksum calculation
>To: erlang-questions@REDACTED
>Message-ID:
> <2306706d-0d84-49a0-97e9-fc6658fbf35f@REDACTED>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Gamoto,
>
>What I would do is:
>1) make a cup of tea,
>2) open my browser to http://www.erlang.org/doc/
>3)...and start doing some reading.
>
>Steve
>
>On Apr 7, 3:55?am, "Gamoto" <gam...@REDACTED> wrote:
>> Richard,
>> Suppose you have an industrial machine which send messages following by the checksum calculated by the xor of all bytes, what can I do with your advices ;-)
>> John
>>
>>
>>
>>
>>
>>
>>
>> >On 6 Apr 2009, at 9:34 pm, Gamoto wrote:
>>
>> >> If it is not a very good solution, would you like to suggest a ?
>> >> better one, for me and the other readers ?\
>>
>> >Suppose you have a block of bytes and there is an
>> >error that results in one byte being replaced by
>> >a different byte. ?Then an XOR checksum will detect
>> >that difference.
>>
>> >Suppose there is an error that results in two bytes
>> >being swapped. ?Then an XOR checksum will detect no
>> >change at all. ?Or suppose that two equal bytes are
>> >both replaced by the same new byte. ?Again, nothing
>> >noticed by XOR.
>>
>> >Just look "checksum" up in the Wikipedia; that's as
>> >good a place as any to start.
>>
>> >The 'zlib' module in Erlang already has support for
>> >crc32 and adler32. ?I thought I saw crc32 somewhere
>> >else as well.
>>
>> >Theory and practice don't agree as much in practice
>> >as they do in theory, so it's worth having a look at
>> >"Performance of Checksums and CRCs over Real Data"
>> >by Jonathan Stone, Michael Greenwald, Craig Partridge,
>> >and Jim Hughes
>> >and at "Revisiting Fletcher and Adler Checksums"
>> >by Theresa Maxino, whose conclusions I found surprising.
>>
>> >It all depends on what your data are like and what
>> >kinds of errors you plausibly need to protect against,
>> >really.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questi...@REDACTED://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>------------------------------
>
>Message: 2
>Date: Wed, 08 Apr 2009 12:27:24 +0100
>From: Oscar Hellstr?m <oscar@REDACTED>
>Subject: Re: [erlang-questions] strange behaviour of gen_tcp:connect
>To: Gamoto <gamoto@REDACTED>
>Cc: erlang-questions <erlang-questions@REDACTED>
>Message-ID: <49DC8A1C.80407@REDACTED>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Hi,
>
>If the port really is free, then you will get a econnrefused, unless you
>have a firewall blocking connection attempts.
>
>Not that I have a windows server 2003 machine, but I'm still seeing at
>least one interesting thing here:
>
>First I start a listening socket on port 6666:
>~% netcat -l -p 6666
>
>Then I configure my iptables to trop all packets on the local interface
>to that port:
># iptables -A INPUT -i lo -p tcp --dport 6666 -j DROP
>
>Then, I start an erlang shell and try to connect to port 6666:
>~% erl
>Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2]
>[async-threads:0] [hipe] [ker
>
>Eshell V5.6.5 (abort with ^G)
>1> gen_tcp:connect({127,0,0,1}, 6666, [binary, {packet, 0}]).
>{error,etimedout}
>
>Ok, wait here now a second, etimedout? This is from the gen_tcp manual:
>connect(Address, Port, Options) -> {ok, Socket} | {error, Reason}
>connect(Address, Port, Options, Timeout) -> {ok, Socket} | {error, Reason}
>...
>Timeout = int() | infinity
>...
>The optional Timeout parameter specifies a timeout in milliseconds. The
>default value is infinity.
>
>So, shouldn't we wait for infinity?
>3> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}]]).
>{189001895,{error,etimedout}}
>5> 189001895 / 1000000 / 60.
>3.150031583333333
>
>It seems the definition of infinity here is 3.15 minutes?
>
>Even when I specify the timeout explicitly I get the same result.
>6> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>infinity]).
>{188997939,{error,etimedout}}
>7> 188997939 / 1000000 / 60.
>3.14996565
>
>Connecting to a different port, which I haven't firewalled I get the
>following:
>8> gen_tcp:connect({127,0,0,1}, 6667, [binary, {packet,
>0}]).
>{error,econnrefused}
>
>Removing the firewall I get:
># iptables -D INPUT -i lo -p tcp --dport 6666 -j DROP
>9> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>infinity]).
>{527,{ok,#Port<0.434>}}
>
>Why is infinity so short?
>
>Gamoto wrote:
>> I an windows server 2003. I don't understand why gen_tcp:connect returns ALWAYS an error.
>> "connect" should be blocking, the port is free, I didn't precise a timeout. I also tried with "localhost".
>> Another strange effect: error returned is "econnrefused" or, when another emacs is opened with erlang code inside, the returned error is "timeout" !!!
>> Is it "normal" with Erlang ?
>>
>> John
>>
>> start()->
>> case gen_tcp:connect("127.0.0.1",1688,[binary, {packet, 0}]) of
>> {ok,Socket}->
>> io:format("Socket established~n"),
>> loop(Socket);
>> {error,Reason}->
>> io:format("Error on connect: ~s~n",[Reason])
>> end.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>Best regards
>
>--
>Oscar Hellstr?m, oscar@REDACTED
>Office: +44 20 7655 0337
>Mobile: +44 798 45 44 773
>Erlang Training and Consulting Ltd
>http://www.erlang-consulting.com/
>
>
>
>------------------------------
>
>Message: 3
>Date: Wed, 8 Apr 2009 22:03:39 +1100
>From: Anthony Shipman <als@REDACTED>
>Subject: [erlang-questions] tcp_send_error
>To: erlang-questions <erlang-questions@REDACTED>
>Message-ID: <200904082103.40041.als@REDACTED>
>Content-Type: text/plain; charset="us-ascii"
>
>I am looking at the source for inet_drv.c in 12B4. In the tcp_send_error()
>function it says
>
> * Note: The following message might get lost, in case the error
> * occurred when we tried to write taken from the queue (no caller).
>
>Can the message really get lost and under what circumstances?
>
>In the kernel application prim_inet:send() the code waits indefinitely for a
>response from the driver. If it can get lost then it looks like a send() can
>block forever. I've got a case where high traffic over a very slow link
>appears to result in prim_inet:send() getting stuck.
>
>--
>Anthony Shipman Mamas don't let your babies
>als@REDACTED grow up to be outsourced.
>
>
>------------------------------
>
>Message: 4
>Date: Wed, 8 Apr 2009 18:07:26 +0530
>From: sameer pradhan <sameer.p.pradhan@REDACTED>
>Subject: [erlang-questions] Erlang on Emacs
>To: erlang-questions@REDACTED
>Message-ID:
> <9ef06be80904080537t2bf00b54m1cfd2d265b907aff@REDACTED>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Can Anybody tell me the full steps, how to run any erlang program on emacs .
>
>--
>Thanks & Regards
>Sameer Prakash Pradhan
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20090408/acc9afc7/attachment-0001.html
>
>------------------------------
>
>Message: 5
>Date: Wed, 8 Apr 2009 15:19:48 +0200
>From: "Gamoto" <gamoto@REDACTED>
>Subject: Re: [erlang-questions] strange behaviour of gen_tcp:connect
>To: " Oscar_Hellstr?m " <oscar@REDACTED>
>Cc: erlang-questions <erlang-questions@REDACTED>
>Message-ID: <200904081519476203619@REDACTED>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi,
>I constated the same with "infinity". We must wait for experts in order to have clarifications ...
>>Hi,
>>
>>If the port really is free, then you will get a econnrefused, unless you
>>have a firewall blocking connection attempts.
>>
>>Not that I have a windows server 2003 machine, but I'm still seeing at
>>least one interesting thing here:
>>
>>First I start a listening socket on port 6666:
>>~% netcat -l -p 6666
>>
>>Then I configure my iptables to trop all packets on the local interface
>>to that port:
>># iptables -A INPUT -i lo -p tcp --dport 6666 -j DROP
>>
>>Then, I start an erlang shell and try to connect to port 6666:
>>~% erl
>>Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2]
>>[async-threads:0] [hipe] [ker
>>
>>Eshell V5.6.5 (abort with ^G)
>>1> gen_tcp:connect({127,0,0,1}, 6666, [binary, {packet, 0}]).
>>{error,etimedout}
>>
>>Ok, wait here now a second, etimedout? This is from the gen_tcp manual:
>>connect(Address, Port, Options) -> {ok, Socket} | {error, Reason}
>>connect(Address, Port, Options, Timeout) -> {ok, Socket} | {error, Reason}
>>...
>>Timeout = int() | infinity
>>...
>>The optional Timeout parameter specifies a timeout in milliseconds. The
>>default value is infinity.
>>
>>So, shouldn't we wait for infinity?
>>3> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}]]).
>>{189001895,{error,etimedout}}
>>5> 189001895 / 1000000 / 60.
>>3.150031583333333
>>
>>It seems the definition of infinity here is 3.15 minutes?
>>
>>Even when I specify the timeout explicitly I get the same result.
>>6> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>>infinity]).
>>{188997939,{error,etimedout}}
>>7> 188997939 / 1000000 / 60.
>>3.14996565
>>
>>Connecting to a different port, which I haven't firewalled I get the
>>following:
>>8> gen_tcp:connect({127,0,0,1}, 6667, [binary, {packet,
>>0}]).
>>{error,econnrefused}
>>
>>Removing the firewall I get:
>># iptables -D INPUT -i lo -p tcp --dport 6666 -j DROP
>>9> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>>infinity]).
>>{527,{ok,#Port<0.434>}}
>>
>>Why is infinity so short?
>>
>>Gamoto wrote:
>>> I an windows server 2003. I don't understand why gen_tcp:connect returns ALWAYS an error.
>>> "connect" should be blocking, the port is free, I didn't precise a timeout. I also tried with "localhost".
>>> Another strange effect: error returned is "econnrefused" or, when another emacs is opened with erlang code inside, the returned error is "timeout" !!!
>>> Is it "normal" with Erlang ?
>>>
>>> John
>>>
>>> start()->
>>> case gen_tcp:connect("127.0.0.1",1688,[binary, {packet, 0}]) of
>>> {ok,Socket}->
>>> io:format("Socket established~n"),
>>> loop(Socket);
>>> {error,Reason}->
>>> io:format("Error on connect: ~s~n",[Reason])
>>> end.
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>Best regards
>>
>>--
>>Oscar Hellstr?m, oscar@REDACTED
>>Office: +44 20 7655 0337
>>Mobile: +44 798 45 44 773
>>Erlang Training and Consulting Ltd
>>http://www.erlang-consulting.com/
>>
>
>------------------------------
>
>Message: 6
>Date: Wed, 8 Apr 2009 16:23:07 +0200
>From: Raimo Niskanen <raimo+erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] : strange behaviour of
> gen_tcp:connect
>To: Oscar Hellstr?m <oscar@REDACTED>,
> erlang-questions@REDACTED
>Message-ID: <20090408142307.GA9872@REDACTED>
>Content-Type: text/plain; charset=iso-8859-1
>
>On Wed, Apr 08, 2009 at 12:27:24PM +0100, Oscar Hellstr?m wrote:
>> Hi,
>>
>> If the port really is free, then you will get a econnrefused, unless you
>> have a firewall blocking connection attempts.
>>
>> Not that I have a windows server 2003 machine, but I'm still seeing at
>> least one interesting thing here:
>>
>> First I start a listening socket on port 6666:
>> ~% netcat -l -p 6666
>>
>> Then I configure my iptables to trop all packets on the local interface
>> to that port:
>> # iptables -A INPUT -i lo -p tcp --dport 6666 -j DROP
>>
>> Then, I start an erlang shell and try to connect to port 6666:
>> ~% erl
>> Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2]
>> [async-threads:0] [hipe] [ker
>>
>> Eshell V5.6.5 (abort with ^G)
>> 1> gen_tcp:connect({127,0,0,1}, 6666, [binary, {packet, 0}]).
>> {error,etimedout}
>>
>> Ok, wait here now a second, etimedout? This is from the gen_tcp manual:
>> connect(Address, Port, Options) -> {ok, Socket} | {error, Reason}
>> connect(Address, Port, Options, Timeout) -> {ok, Socket} | {error, Reason}
>> ...
>> Timeout = int() | infinity
>> ...
>> The optional Timeout parameter specifies a timeout in milliseconds. The
>> default value is infinity.
>>
>> So, shouldn't we wait for infinity?
>> 3> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}]]).
>> {189001895,{error,etimedout}}
>> 5> 189001895 / 1000000 / 60.
>> 3.150031583333333
>>
>> It seems the definition of infinity here is 3.15 minutes?
>
>It is most probably the definition of fatal timeout in the
>TCP stack. So the man page forget to mention that if
>the OS connect() call returns with a timeout, gen_tcp:connect
>will also return with a timeout, even if none was specified.
>
>>
>> Even when I specify the timeout explicitly I get the same result.
>> 6> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>> infinity]).
>> {188997939,{error,etimedout}}
>> 7> 188997939 / 1000000 / 60.
>> 3.14996565
>>
>> Connecting to a different port, which I haven't firewalled I get the
>> following:
>> 8> gen_tcp:connect({127,0,0,1}, 6667, [binary, {packet,
>> 0}]).
>> {error,econnrefused}
>>
>> Removing the firewall I get:
>> # iptables -D INPUT -i lo -p tcp --dport 6666 -j DROP
>> 9> timer:tc(gen_tcp, connect, [{127,0,0,1}, 6666, [binary, {packet, 0}],
>> infinity]).
>> {527,{ok,#Port<0.434>}}
>>
>> Why is infinity so short?
>:
>
>--
>
>/ Raimo Niskanen, Erlang/OTP, Ericsson AB
>
>
>------------------------------
>
>Message: 7
>Date: Wed, 08 Apr 2009 16:28:12 +0200
>From: Sverker Eriksson <sverker@REDACTED>
>Subject: Re: [erlang-questions] tcp_send_error
>Cc: erlang-questions <erlang-questions@REDACTED>
>Message-ID: <49DCB47C.5070902@REDACTED>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Anthony Shipman wrote:
>> I am looking at the source for inet_drv.c in 12B4. In the tcp_send_error()
>> function it says
>>
>> * Note: The following message might get lost, in case the error
>> * occurred when we tried to write taken from the queue (no caller).
>>
>> Can the message really get lost and under what circumstances?
>>
>>
>When the process is not blocking in prim_inet:send() waiting for a
>reply. That is, the send operation was done asynchronous triggered by an
>internal polled write-event from the socket.
>
>> In the kernel application prim_inet:send() the code waits indefinitely for a
>> response from the driver. If it can get lost then it looks like a send() can
>> block forever. I've got a case where high traffic over a very slow link
>> appears to result in prim_inet:send() getting stuck.
>>
>>
>Changes have been made to that code in R12B-5, R13A, R13B. Here are two
>fixes in the release notes regarding hanging send's:
>
>R13A:
>Calling gen_tcp:send() from several processes on socket with option
>send_timeout
>could lead to much longer timeout than specified. The solution is a new
>socket option
>{send_timeout_close,true} that will do automatic close on timeout.
>Subsequent calls
>to send will then immediately fail due to the closed connection.
>
>Coming R13B:
>Fixed a bug on Windows that could make gen_tcp:send hang trying to send
>an iolist
>of more than 16 binaries.
>
>
>/Sverker, Erlang/OTP Ericsson
>
>
>
>
>------------------------------
>
>Message: 8
>Date: Wed, 08 Apr 2009 19:21:29 +0200
>From: Franco Milicchio <fmilicchio@REDACTED>
>Subject: Re: [erlang-questions] State of the Union: FFI
>To: Zvi <exta7@REDACTED>
>Cc: erlang-questions@REDACTED
>Message-ID: <01D2B728-D19B-4923-A5A8-DE08CC70A908@REDACTED>
>Content-Type: text/plain; charset="us-ascii"
>
>I have started porting the patch to R13A, although I can't say if it
>really works: it doesn't compile! Makefile error, not a C one :)
>
>You may find the source code at: http://plm.dia.uniroma3.it/milicchio/public/otp_src_R13A-ffi.zip
> (62 MB)
>
>
>I have no time left today, but if we all start figuring out what's
>wrong with it, we may end up having the FFI working on this new
>release. I have marked the C code with comments (/* FFI START */ and /
>* FFI END */) where I had doubts about applying Alceste's patch, so it
>should be easy to spot them.
>
>By the way, no news about the reason FFI hasn't been taken into
>account yet?
>
>Cheers!
>
>--
>Franco Milicchio <fmilicchio@REDACTED>
>
>DIA - Dept. of Computer Science and Engineering
>University Roma Tre
>http://plm.dia.uniroma3.it/milicchio/
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: smime.p7s
>Type: application/pkcs7-signature
>Size: 2417 bytes
>Desc: not available
>Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20090408/f0963b9e/attachment.bin
>
>------------------------------
>
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://www.erlang.org/mailman/listinfo/erlang-questions
>
>End of erlang-questions Digest, Vol 23, Issue 29
>************************************************
More information about the erlang-questions
mailing list