From max.lapshin@REDACTED Sat Jul 11 14:48:26 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 11 Jul 2015 15:48:26 +0300 Subject: [erlang-patches] DTLS patch In-Reply-To: References: <1093525126.101068.1433085768186.JavaMail.zimbra@tpip.net> <556C5EDC.2040307@ericsson.com> Message-ID: I don't know exactly what to do with DTLS in my case, because I need to use the same udp socket for different kinds of communication. So I need to change protocol handler on socket. Right now I'm thinking about reimplementing DTLS by my hands and this idea is scarying me a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.karlsson@REDACTED Sat Jul 11 15:47:58 2015 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sat, 11 Jul 2015 15:47:58 +0200 Subject: [erlang-patches] DTLS patch In-Reply-To: References: Message-ID: <20150711154751.2D0F.69B9F832@proxel.se> Why do you want to reuse the socket? Why not just close it and open a new? /Roland On Sat, 11 Jul 2015 15:48:26 +0300 Max Lapshin wrote: > I don't know exactly what to do with DTLS in my case, because I need to use > the same udp socket for different kinds of communication. > > So I need to change protocol handler on socket. > > Right now I'm thinking about reimplementing DTLS by my hands and this idea > is scarying me a lot. From aschultz@REDACTED Sun Jul 12 05:11:06 2015 From: aschultz@REDACTED (Andreas Schultz) Date: Sun, 12 Jul 2015 05:11:06 +0200 (CEST) Subject: [erlang-patches] DTLS patch Message-ID: Am 11.07.2015 15:47 schrieb Roland Karlsson : > > Why do you want to reuse the socket? > Why not just close it and open a new? There are protocols where you have to multiplex DTLS and normal data over the same socket Andreas > > /Roland > > > > On Sat, 11 Jul 2015 15:48:26 +0300 > Max Lapshin wrote: > > > I don't know exactly what to do with DTLS in my case, because I need to use > > the same udp socket for different kinds of communication. > > > > So I need to change protocol handler on socket. > > > > Right now I'm thinking about reimplementing DTLS by my hands and this idea > > is scarying? me a lot. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From max.lapshin@REDACTED Sun Jul 12 06:44:44 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 12 Jul 2015 07:44:44 +0300 Subject: [erlang-patches] DTLS patch In-Reply-To: References: Message-ID: Because client will send data to the same port and it doesn't care that I use library that doesn't allow me something. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Jul 13 11:18:42 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 13 Jul 2015 12:18:42 +0300 Subject: [erlang-patches] DTLS patch In-Reply-To: References: Message-ID: Well, implementing DTLS is a very nice thing =) I'm trying to look if it is possible to reuse existing SSL implementation for it, but it seems that it is rather hard, because erlang SSL is a very self-contained thing, designed for isolated usage, not like a library on top of existing socket. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Mon Jul 13 11:52:15 2015 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 13 Jul 2015 11:52:15 +0200 (CEST) Subject: [erlang-patches] DTLS patch In-Reply-To: References: Message-ID: <916291675.1965705.1436781135653.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > From: "Max Lapshin" > To: "Andreas Schultz" > Cc: "Roland Karlsson" , "erlang-patches" , "Haiyang Yin" > > Sent: Monday, July 13, 2015 11:18:42 AM > Subject: Re: [erlang-patches] DTLS patch > Well, implementing DTLS is a very nice thing =) > I'm trying to look if it is possible to reuse existing SSL implementation for > it, but it seems that it is rather hard, because erlang SSL is a very > self-contained thing, designed for isolated usage, not like a library on top of > existing socket. Well, the TLS code has a concept of a transport call back module for abstracting the underlying socket. There is no documentation for that and it's (IMO) not very consistent either. For my version, I used that and implemented a UDP socket wrapper call back module. For your case, you could use that socket wrapper as a starting point and modify it. That's what I do for CAPWAP DTLS support. I believe Haiyang Yin patch has a very similar mechanism. The cb module is called dtls_transport and utilizes dtls_socket_manager and dtls_socket_server. Just extract them, rename and alter to your needs, then pass your version as cb_info argument into the ssl socket setup. Andreas From max.lapshin@REDACTED Mon Jul 13 13:18:21 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 13 Jul 2015 14:18:21 +0300 Subject: [erlang-patches] DTLS patch In-Reply-To: <916291675.1965705.1436781135653.JavaMail.zimbra@tpip.net> References: <916291675.1965705.1436781135653.JavaMail.zimbra@tpip.net> Message-ID: Ok, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruanbeihong@REDACTED Tue Jul 21 09:45:30 2015 From: ruanbeihong@REDACTED (ruanbeihong) Date: Tue, 21 Jul 2015 15:45:30 +0800 Subject: [erlang-patches] [erlang-questions] How to Update List Elements A Lot In-Reply-To: References: Message-ID: <130686808.RIbp0jHrDa@debian> I think it's the last thing to think about when writing codes. You'd expect the compiler to do such 'update inline' optimization for you. I'm not quite sure that the compiler do does that kind of optimization, but I will consider to use C port when performance is really critical problem when profile test proved it. On Tuesday 21 July 2015 12:00:04 Hugo Wang wrote: Hi all, I'm writing an encrypt/decrypt stuff in Erlang, the input and output are both lists (or binary). In other words, I need to generate a list of bytes based on another list of bytes. During the generating there are a lot of band, bor, bxor, bsl, bsr, etc operations. Every element in the new list (the output) would be updated many times. In other language, like C or Python, we can init an output list and then update its elements inline. In Erlang, what I currently do, would make a copy of the list every time when an element need to update. This looks not quite right. Any comments/ideas on this? I want to use pure Erlang to implement it, rather than making a C port. Thanks, Hugo James Ruan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Jul 21 16:16:15 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 21 Jul 2015 16:16:15 +0200 Subject: [erlang-patches] [erlang-questions] How to Update List Elements A Lot In-Reply-To: <130686808.RIbp0jHrDa@debian> References: <130686808.RIbp0jHrDa@debian> Message-ID: On Tue, Jul 21, 2015 at 9:45 AM, ruanbeihong wrote: > I think it's the last thing to think about when writing codes. You'd > expect the compiler to do such 'update inline' optimization for you. It is a very true statement. But there are limits to what kind of transformations you can expect of a compiler. If you have used lists with lots of lists:keyreplace/4 for instance, then the compiler is not clever enough to transform this to a list comprehension, which turns an O(n^2) algorithm into a O(n) algorithm. Also, there are limits to a functional programming language. In-place updates requires the compiler to prove that access to the data is truly linear. If you have lots of cross-module calls, the Erlang evaluation model somewhat constrains you, because if a module is loaded while the cross-module calls are being done, then you expect the code to jump to the new version. And the new version may use the data in a non-linear fashion. Programming languages which support linear access for updates usually annotate access in a type/effect system (ATS, Rust comes to mind). And thus they have an easier time optimizing since they can rely on the program being well-typed or well-effected. All of this said, functional languages commonly have GCs which are extremely good at handling high allocation rates. Non-live data on the heap has 0 reclamation cost in the Erlang BEAM VMs GC for instance. The primary problem here is the memory bottleneck in modern CPUs: papers from the 90'es show that usually, memory is less of an issue than first thought. But here, 20 years later, it is about time to redo those old findings. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: