Re: Anti-hacker security restrictions on UDP?
LOTS of folks implement their own protocol on top of UDP instead of TCP to get some, but not all, of the features of TCP. TCP has a whole lot of features that slow it down, and if you don’t need all of them, why pay for them, particularly if you are writing time-critical applications? Sometimes you just don’t need a virtual circuit, flow control, etc. http://www.diffen.com/difference/TCP_vs_UDP From: <owner-lisp-hug@lispworks.com> on behalf of David McClain <dbm@refined-audiometrics.com> Reply-To: David McClain <dbm@refined-audiometrics.com> Date: Tuesday, October 3, 2017 at 10:26 AM To: Lispworks HUG <lisp-hug@lispworks.com> Subject: EXT: Re: Anti-hacker security restrictions on UDP? Hi binghe, That sounds very interesting… but I’m curious about why you want to reinvent the reliability of TCP/IP using UDP? If you need this kind of reliability then why not just use TCP/IP? And how could you possibly re-transmit a lost packet unless the sender were informed of this loss - which is part of the protocol embedded in TCP/IP? - DM On Oct 3, 2017, at 05:43, Chun Tian (binghe) <binghe.lisp@gmail.com<mailto:binghe.lisp@gmail.com>> wrote: I never heard "CLUDP", but my LispWorks-UDP project [1] was used by IRCAM in their OMAX music-related software [2], its public available OMax 3.0 sources still contains old version of my code. Whenever the specific UDP protocol contains a sequential number indicating the order of packets, my package has the ability to automatic retransmit lost UDP packets using a TCP-like RTT algorithm (this part is not ported to USOCKET [3], which provides synchronized LispWorks/UDP API). [1] https://github.com/binghe/lispworks-udp [2] http://repmus.ircam.fr/omax/home [3] https://common-lisp.net/project/usocket/ On 2 October 2017 at 15:41, David McClain <dbm@refined-audiometrics.com<mailto:dbm@refined-audiometrics.com>> wrote: Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time. And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm. Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com<http://kyma.symbolicsound.com/> ) - DM On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com<mailto:erik.ronstrom@doremir.com>> wrote: UDP is supported natively by LispWorks, at least in LW 7.0: http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm Of course, if you want it portable, an external module could still be preferred. As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice. Erik 1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com<mailto:dbm@refined-audiometrics.com>>: … sorry for the noise… I found the problems in CLUDP itself. 1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the .c and .h source files. This so that the C++ compile won’t mangle the names on you. 2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay. - DM On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com<mailto:cstacy@dtpq.com>> wrote: UDP is a supported "socket" API on OSX. Your problem could conceivably be security related, but not about UDP per se. _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com> http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com> http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com> http://www.lispworks.com/support/lisp-hug.html -- Chun Tian (binghe) University of Bologna (Italy) _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html