oscpack TCP
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
oscpack TCP
by Martin Kaltenbrunner
::
Rate this Message:
Hello,
we are planning to add TCP support and other alternative transport methods to oscpack. I've read some threads on the topic, but I wasn't able to find any specific code yet. Before we start from scratch, I'd like to ask if eventually someone already has done some work on that? best, Martin.K _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Sciss-3
::
Rate this Message:
netutil ( http://sourceforge.net/projects/netutil ) supports TCP, but
that is java, i assume you are looking for C(++) code? Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: > Hello, > we are planning to add TCP support and other alternative transport > methods to oscpack. > > I've read some threads on the topic, but I wasn't able to find any > specific code yet. Before we start from scratch, I'd like to ask if > eventually someone already has done some work on that? > > best, > Martin.K > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Sciss-3
::
Rate this Message:
p.s. and supercollider supports TCP, so you have some C code there. i
don't know how well separated the OSC part is from the rest of the programme, though. Am 12.08.2009 um 13:13 schrieb Sciss: > netutil ( http://sourceforge.net/projects/netutil ) supports TCP, but > that is java, i assume you are looking for C(++) code? > > Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: > >> Hello, >> we are planning to add TCP support and other alternative transport >> methods to oscpack. >> >> I've read some threads on the topic, but I wasn't able to find any >> specific code yet. Before we start from scratch, I'd like to ask if >> eventually someone already has done some work on that? >> >> best, >> Martin.K >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Stephen Sinclair
::
Rate this Message:
Hello,
There is a TCP implementation in LibLo. Since the last version, it now retains sessions instead of closing after sending a single message. What I have _not_ done is thoroughly tested it against other TCP implementations, which would be an excellent step forward. Steve On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: > p.s. and supercollider supports TCP, so you have some C code there. i > don't know how well separated the OSC part is from the rest of the > programme, though. > > Am 12.08.2009 um 13:13 schrieb Sciss: > >> netutil ( http://sourceforge.net/projects/netutil ) supports TCP, but >> that is java, i assume you are looking for C(++) code? >> >> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >> >>> Hello, >>> we are planning to add TCP support and other alternative transport >>> methods to oscpack. >>> >>> I've read some threads on the topic, but I wasn't able to find any >>> specific code yet. Before we start from scratch, I'd like to ask if >>> eventually someone already has done some work on that? >>> >>> best, >>> Martin.K >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Martin Kaltenbrunner
::
Rate this Message:
Hello Steve (and others),
thanks for the hints on the various alternative OSC/TCP implementations! Since I am planning to add TCP (and other alternative transports) to some multi-platform TUIO implementations, I will probably later also go on with adding this to JavaOSC and OSC.NET, which are used in these packages, just as oscpack. I think liblo might be a good reference for an oscpack TCP layer. Since we actually need the TCP support within oscpack itself, some code snippets might be helpful. My question was if somebody had done some work on TCP for oscpack in particular. best, Martin.K Am 12.08.09 17:05, schrieb Stephen Sinclair: > Hello, > > There is a TCP implementation in LibLo. Since the last version, it > now retains sessions instead of closing after sending a single > message. What I have _not_ done is thoroughly tested it against other > TCP implementations, which would be an excellent step forward. > > > Steve > > > On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >> p.s. and supercollider supports TCP, so you have some C code there. i >> don't know how well separated the OSC part is from the rest of the >> programme, though. >> >> Am 12.08.2009 um 13:13 schrieb Sciss: >> >>> netutil ( http://sourceforge.net/projects/netutil ) supports TCP, but >>> that is java, i assume you are looking for C(++) code? >>> >>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>> >>>> Hello, >>>> we are planning to add TCP support and other alternative transport >>>> methods to oscpack. >>>> >>>> I've read some threads on the topic, but I wasn't able to find any >>>> specific code yet. Before we start from scratch, I'd like to ask if >>>> eventually someone already has done some work on that? >>>> >>>> best, >>>> Martin.K >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Stephen Sinclair
::
Rate this Message:
Great!
If you come up with any suggestions for improvements to the TCP layer in liblo (or find any bugs), please don't hesitate to make them. There may very well be details that need agreeing on, and I don't know of anyone seriously using the TCP implementation right now so it's better to change things if it needs it. thanks, Steve On Wed, Aug 12, 2009 at 11:42 AM, Martin Kaltenbrunner<modin@...> wrote: > Hello Steve (and others), > thanks for the hints on the various alternative OSC/TCP implementations! > > Since I am planning to add TCP (and other alternative transports) to > some multi-platform TUIO implementations, I will probably later also go > on with adding this to JavaOSC and OSC.NET, which are used in these > packages, just as oscpack. > > I think liblo might be a good reference for an oscpack TCP layer. Since > we actually need the TCP support within oscpack itself, some code > snippets might be helpful. My question was if somebody had done some > work on TCP for oscpack in particular. > > best, > Martin.K > > > Am 12.08.09 17:05, schrieb Stephen Sinclair: >> Hello, >> >> There is a TCP implementation in LibLo. Since the last version, it >> now retains sessions instead of closing after sending a single >> message. What I have _not_ done is thoroughly tested it against other >> TCP implementations, which would be an excellent step forward. >> >> >> Steve >> >> >> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>> p.s. and supercollider supports TCP, so you have some C code there. i >>> don't know how well separated the OSC part is from the rest of the >>> programme, though. >>> >>> Am 12.08.2009 um 13:13 schrieb Sciss: >>> >>>> netutil ( http://sourceforge.net/projects/netutil ) supports TCP, but >>>> that is java, i assume you are looking for C(++) code? >>>> >>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>> >>>>> Hello, >>>>> we are planning to add TCP support and other alternative transport >>>>> methods to oscpack. >>>>> >>>>> I've read some threads on the topic, but I wasn't able to find any >>>>> specific code yet. Before we start from scratch, I'd like to ask if >>>>> eventually someone already has done some work on that? >>>>> >>>>> best, >>>>> Martin.K >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Andy W. Schmeder-2
::
Rate this Message:
How does liblo frame the packets on TCP?
We have been using double-ended SLIP on USB-serial and it has many nice properties, such as clean recovery if the stream is interrupted and restarted. The recommendation given in the 1.0 spec is not so great... On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: > Great! > > If you come up with any suggestions for improvements to the TCP layer > in liblo (or find any bugs), please don't hesitate to make them. > There may very well be details that need agreeing on, and I don't know > of anyone seriously using the TCP implementation right now so it's > better to change things if it needs it. > > thanks, > Steve > > > On Wed, Aug 12, 2009 at 11:42 AM, Martin > Kaltenbrunner<modin@...> wrote: >> Hello Steve (and others), >> thanks for the hints on the various alternative OSC/TCP >> implementations! >> >> Since I am planning to add TCP (and other alternative transports) to >> some multi-platform TUIO implementations, I will probably later >> also go >> on with adding this to JavaOSC and OSC.NET, which are used in these >> packages, just as oscpack. >> >> I think liblo might be a good reference for an oscpack TCP layer. >> Since >> we actually need the TCP support within oscpack itself, some code >> snippets might be helpful. My question was if somebody had done some >> work on TCP for oscpack in particular. >> >> best, >> Martin.K >> >> >> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>> Hello, >>> >>> There is a TCP implementation in LibLo. Since the last version, it >>> now retains sessions instead of closing after sending a single >>> message. What I have _not_ done is thoroughly tested it against >>> other >>> TCP implementations, which would be an excellent step forward. >>> >>> >>> Steve >>> >>> >>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>>> p.s. and supercollider supports TCP, so you have some C code >>>> there. i >>>> don't know how well separated the OSC part is from the rest of the >>>> programme, though. >>>> >>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>> >>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>> TCP, but >>>>> that is java, i assume you are looking for C(++) code? >>>>> >>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>> >>>>>> Hello, >>>>>> we are planning to add TCP support and other alternative >>>>>> transport >>>>>> methods to oscpack. >>>>>> >>>>>> I've read some threads on the topic, but I wasn't able to find >>>>>> any >>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>> ask if >>>>>> eventually someone already has done some work on that? >>>>>> >>>>>> best, >>>>>> Martin.K >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev --- Andy W. Schmeder andy [at] cnmat.berkeley.edu Programmer/Analyst II Research Group Center for New Music and Audio Technologies University of California at Berkeley http://cnmat.berkeley.edu _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Stephen Sinclair
::
Rate this Message:
It just sends the length of the message, and then the message data.
If the stream is interrupted, the message must be restarted. Isn't the whole point of TCP to be a reliable protocol? Steve On Wed, Aug 12, 2009 at 6:16 PM, Andy W. Schmeder<andy@...> wrote: > How does liblo frame the packets on TCP? > > We have been using double-ended SLIP on USB-serial and it has many > nice properties, such as clean recovery if the stream is interrupted > and restarted. The recommendation given in the 1.0 spec is not so > great... > > > On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: > >> Great! >> >> If you come up with any suggestions for improvements to the TCP layer >> in liblo (or find any bugs), please don't hesitate to make them. >> There may very well be details that need agreeing on, and I don't know >> of anyone seriously using the TCP implementation right now so it's >> better to change things if it needs it. >> >> thanks, >> Steve >> >> >> On Wed, Aug 12, 2009 at 11:42 AM, Martin >> Kaltenbrunner<modin@...> wrote: >>> Hello Steve (and others), >>> thanks for the hints on the various alternative OSC/TCP >>> implementations! >>> >>> Since I am planning to add TCP (and other alternative transports) to >>> some multi-platform TUIO implementations, I will probably later >>> also go >>> on with adding this to JavaOSC and OSC.NET, which are used in these >>> packages, just as oscpack. >>> >>> I think liblo might be a good reference for an oscpack TCP layer. >>> Since >>> we actually need the TCP support within oscpack itself, some code >>> snippets might be helpful. My question was if somebody had done some >>> work on TCP for oscpack in particular. >>> >>> best, >>> Martin.K >>> >>> >>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>> Hello, >>>> >>>> There is a TCP implementation in LibLo. Since the last version, it >>>> now retains sessions instead of closing after sending a single >>>> message. What I have _not_ done is thoroughly tested it against >>>> other >>>> TCP implementations, which would be an excellent step forward. >>>> >>>> >>>> Steve >>>> >>>> >>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>>>> p.s. and supercollider supports TCP, so you have some C code >>>>> there. i >>>>> don't know how well separated the OSC part is from the rest of the >>>>> programme, though. >>>>> >>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>> >>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>> TCP, but >>>>>> that is java, i assume you are looking for C(++) code? >>>>>> >>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>> >>>>>>> Hello, >>>>>>> we are planning to add TCP support and other alternative >>>>>>> transport >>>>>>> methods to oscpack. >>>>>>> >>>>>>> I've read some threads on the topic, but I wasn't able to find >>>>>>> any >>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>> ask if >>>>>>> eventually someone already has done some work on that? >>>>>>> >>>>>>> best, >>>>>>> Martin.K >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > > --- > > Andy W. Schmeder > andy [at] cnmat.berkeley.edu > > Programmer/Analyst II > Research Group > Center for New Music and Audio Technologies > University of California at Berkeley > http://cnmat.berkeley.edu > > > > > > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Martin Kaltenbrunner
::
Rate this Message:
Hey Steve,
I actually wanted to discuss this topic as well. In my opinion, a OSC/TCP connection should just send the OSC data without any other header or length information. The receiver then can take care of the proper segmentation, when looking at the incoming data stream OSC bundles can be identified accordingly. I guess this should be the "proper" way although I am not aware if there are some notes on this case in the OSC documentation. For TUIO we are already using OSC/TCP for Flash connections, where this raw OSC approach works quite fine. There is already a OSC/TUIO ActionScript library by Dean North which does the job quite well. Actually we are now working on a proper OSC/TCP implementation for AS3 for a new TUIO Flash library. There are already a few UDP/TCP gateways available for that purpose, which just hand the UDP packet content to a TCP connection without modification or metadata. Apart from Dean's touchgateway, Memo Akten also created a very generic UDP/TCP bridge. http://www.touchgateway.com/ http://code.google.com/p/udp-tcp-bridge/ so maybe we should talk about how to keep the TCP implementations in sync to come to a compatible solution. best, Martin.K Am 13.08.09 03:19, schrieb Stephen Sinclair: > It just sends the length of the message, and then the message data. > If the stream is interrupted, the message must be restarted. Isn't > the whole point of TCP to be a reliable protocol? > > Steve > > > On Wed, Aug 12, 2009 at 6:16 PM, Andy W. > Schmeder<andy@...> wrote: >> How does liblo frame the packets on TCP? >> >> We have been using double-ended SLIP on USB-serial and it has many >> nice properties, such as clean recovery if the stream is interrupted >> and restarted. The recommendation given in the 1.0 spec is not so >> great... >> >> >> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >> >>> Great! >>> >>> If you come up with any suggestions for improvements to the TCP layer >>> in liblo (or find any bugs), please don't hesitate to make them. >>> There may very well be details that need agreeing on, and I don't know >>> of anyone seriously using the TCP implementation right now so it's >>> better to change things if it needs it. >>> >>> thanks, >>> Steve >>> >>> >>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>> Kaltenbrunner<modin@...> wrote: >>>> Hello Steve (and others), >>>> thanks for the hints on the various alternative OSC/TCP >>>> implementations! >>>> >>>> Since I am planning to add TCP (and other alternative transports) to >>>> some multi-platform TUIO implementations, I will probably later >>>> also go >>>> on with adding this to JavaOSC and OSC.NET, which are used in these >>>> packages, just as oscpack. >>>> >>>> I think liblo might be a good reference for an oscpack TCP layer. >>>> Since >>>> we actually need the TCP support within oscpack itself, some code >>>> snippets might be helpful. My question was if somebody had done some >>>> work on TCP for oscpack in particular. >>>> >>>> best, >>>> Martin.K >>>> >>>> >>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>> Hello, >>>>> >>>>> There is a TCP implementation in LibLo. Since the last version, it >>>>> now retains sessions instead of closing after sending a single >>>>> message. What I have _not_ done is thoroughly tested it against >>>>> other >>>>> TCP implementations, which would be an excellent step forward. >>>>> >>>>> >>>>> Steve >>>>> >>>>> >>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>> there. i >>>>>> don't know how well separated the OSC part is from the rest of the >>>>>> programme, though. >>>>>> >>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>> >>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>> TCP, but >>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>> >>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>> >>>>>>>> Hello, >>>>>>>> we are planning to add TCP support and other alternative >>>>>>>> transport >>>>>>>> methods to oscpack. >>>>>>>> >>>>>>>> I've read some threads on the topic, but I wasn't able to find >>>>>>>> any >>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>> ask if >>>>>>>> eventually someone already has done some work on that? >>>>>>>> >>>>>>>> best, >>>>>>>> Martin.K >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> >> --- >> >> Andy W. Schmeder >> andy [at] cnmat.berkeley.edu >> >> Programmer/Analyst II >> Research Group >> Center for New Music and Audio Technologies >> University of California at Berkeley >> http://cnmat.berkeley.edu >> >> >> >> >> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Stephen Sinclair
::
Rate this Message:
I think LibLo gives the length because of this note in the 1.0 spec
(section OSC Packets): "In a stream-based protocol such as TCP, the stream should begin with an int32 giving the size of the first packet, followed by the contents of the first packet, followed by the size of the second packet, etc." I agree that using a 'raw' approach would be best if it can be done, although I guess the rationale is that sending the size initially can be useful for a program that needs to allocate a buffer before reading the data. Does anyone know offhand whether Max/MSP and Pd's mrpeach implementations handle this differently? Steve On Thu, Aug 13, 2009 at 3:24 AM, Martin Kaltenbrunner<modin@...> wrote: > Hey Steve, > I actually wanted to discuss this topic as well. > In my opinion, a OSC/TCP connection should just send the OSC data > without any other header or length information. The receiver then can > take care of the proper segmentation, when looking at the incoming data > stream OSC bundles can be identified accordingly. I guess this should be > the "proper" way although I am not aware if there are some notes on this > case in the OSC documentation. > > For TUIO we are already using OSC/TCP for Flash connections, where this > raw OSC approach works quite fine. There is already a OSC/TUIO > ActionScript library by Dean North which does the job quite well. > Actually we are now working on a proper OSC/TCP implementation for AS3 > for a new TUIO Flash library. > > There are already a few UDP/TCP gateways available for that purpose, > which just hand the UDP packet content to a TCP connection without > modification or metadata. Apart from Dean's touchgateway, Memo Akten > also created a very generic UDP/TCP bridge. > > http://www.touchgateway.com/ > http://code.google.com/p/udp-tcp-bridge/ > > so maybe we should talk about how to keep the TCP implementations in > sync to come to a compatible solution. > best, Martin.K > > > Am 13.08.09 03:19, schrieb Stephen Sinclair: >> It just sends the length of the message, and then the message data. >> If the stream is interrupted, the message must be restarted. Isn't >> the whole point of TCP to be a reliable protocol? >> >> Steve >> >> >> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >> Schmeder<andy@...> wrote: >>> How does liblo frame the packets on TCP? >>> >>> We have been using double-ended SLIP on USB-serial and it has many >>> nice properties, such as clean recovery if the stream is interrupted >>> and restarted. The recommendation given in the 1.0 spec is not so >>> great... >>> >>> >>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>> >>>> Great! >>>> >>>> If you come up with any suggestions for improvements to the TCP layer >>>> in liblo (or find any bugs), please don't hesitate to make them. >>>> There may very well be details that need agreeing on, and I don't know >>>> of anyone seriously using the TCP implementation right now so it's >>>> better to change things if it needs it. >>>> >>>> thanks, >>>> Steve >>>> >>>> >>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>> Kaltenbrunner<modin@...> wrote: >>>>> Hello Steve (and others), >>>>> thanks for the hints on the various alternative OSC/TCP >>>>> implementations! >>>>> >>>>> Since I am planning to add TCP (and other alternative transports) to >>>>> some multi-platform TUIO implementations, I will probably later >>>>> also go >>>>> on with adding this to JavaOSC and OSC.NET, which are used in these >>>>> packages, just as oscpack. >>>>> >>>>> I think liblo might be a good reference for an oscpack TCP layer. >>>>> Since >>>>> we actually need the TCP support within oscpack itself, some code >>>>> snippets might be helpful. My question was if somebody had done some >>>>> work on TCP for oscpack in particular. >>>>> >>>>> best, >>>>> Martin.K >>>>> >>>>> >>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>> Hello, >>>>>> >>>>>> There is a TCP implementation in LibLo. Since the last version, it >>>>>> now retains sessions instead of closing after sending a single >>>>>> message. What I have _not_ done is thoroughly tested it against >>>>>> other >>>>>> TCP implementations, which would be an excellent step forward. >>>>>> >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>> there. i >>>>>>> don't know how well separated the OSC part is from the rest of the >>>>>>> programme, though. >>>>>>> >>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>> >>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>> TCP, but >>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>> >>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>> transport >>>>>>>>> methods to oscpack. >>>>>>>>> >>>>>>>>> I've read some threads on the topic, but I wasn't able to find >>>>>>>>> any >>>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>>> ask if >>>>>>>>> eventually someone already has done some work on that? >>>>>>>>> >>>>>>>>> best, >>>>>>>>> Martin.K >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >>> --- >>> >>> Andy W. Schmeder >>> andy [at] cnmat.berkeley.edu >>> >>> Programmer/Analyst II >>> Research Group >>> Center for New Music and Audio Technologies >>> University of California at Berkeley >>> http://cnmat.berkeley.edu >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Sciss-3
::
Rate this Message:
supercollider and netutil use this specification of osc 1.0 : packet
size (int32), then the data. i think it is very useful for efficient read-in to have this size. i don't see any advantage removing this information. the tcp in supercollider is rock solid since years and i think following this spec is a good thing. ciao, -sciss- Am 13.08.2009 um 16:08 schrieb Stephen Sinclair: > I think LibLo gives the length because of this note in the 1.0 spec > (section OSC Packets): > > "In a stream-based protocol such as TCP, the stream should begin with > an int32 giving the size of the first packet, followed by the contents > of the first packet, followed by the size of the second packet, etc." > > I agree that using a 'raw' approach would be best if it can be done, > although I guess the rationale is that sending the size initially can > be useful for a program that needs to allocate a buffer before reading > the data. > > Does anyone know offhand whether Max/MSP and Pd's mrpeach > implementations handle this differently? > > Steve > > > On Thu, Aug 13, 2009 at 3:24 AM, Martin > Kaltenbrunner<modin@...> wrote: >> Hey Steve, >> I actually wanted to discuss this topic as well. >> In my opinion, a OSC/TCP connection should just send the OSC data >> without any other header or length information. The receiver then can >> take care of the proper segmentation, when looking at the incoming >> data >> stream OSC bundles can be identified accordingly. I guess this >> should be >> the "proper" way although I am not aware if there are some notes >> on this >> case in the OSC documentation. >> >> For TUIO we are already using OSC/TCP for Flash connections, where >> this >> raw OSC approach works quite fine. There is already a OSC/TUIO >> ActionScript library by Dean North which does the job quite well. >> Actually we are now working on a proper OSC/TCP implementation for >> AS3 >> for a new TUIO Flash library. >> >> There are already a few UDP/TCP gateways available for that purpose, >> which just hand the UDP packet content to a TCP connection without >> modification or metadata. Apart from Dean's touchgateway, Memo Akten >> also created a very generic UDP/TCP bridge. >> >> http://www.touchgateway.com/ >> http://code.google.com/p/udp-tcp-bridge/ >> >> so maybe we should talk about how to keep the TCP implementations in >> sync to come to a compatible solution. >> best, Martin.K >> >> >> Am 13.08.09 03:19, schrieb Stephen Sinclair: >>> It just sends the length of the message, and then the message data. >>> If the stream is interrupted, the message must be restarted. Isn't >>> the whole point of TCP to be a reliable protocol? >>> >>> Steve >>> >>> >>> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >>> Schmeder<andy@...> wrote: >>>> How does liblo frame the packets on TCP? >>>> >>>> We have been using double-ended SLIP on USB-serial and it has many >>>> nice properties, such as clean recovery if the stream is >>>> interrupted >>>> and restarted. The recommendation given in the 1.0 spec is not so >>>> great... >>>> >>>> >>>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>>> >>>>> Great! >>>>> >>>>> If you come up with any suggestions for improvements to the TCP >>>>> layer >>>>> in liblo (or find any bugs), please don't hesitate to make them. >>>>> There may very well be details that need agreeing on, and I >>>>> don't know >>>>> of anyone seriously using the TCP implementation right now so it's >>>>> better to change things if it needs it. >>>>> >>>>> thanks, >>>>> Steve >>>>> >>>>> >>>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>>> Kaltenbrunner<modin@...> wrote: >>>>>> Hello Steve (and others), >>>>>> thanks for the hints on the various alternative OSC/TCP >>>>>> implementations! >>>>>> >>>>>> Since I am planning to add TCP (and other alternative >>>>>> transports) to >>>>>> some multi-platform TUIO implementations, I will probably later >>>>>> also go >>>>>> on with adding this to JavaOSC and OSC.NET, which are used in >>>>>> these >>>>>> packages, just as oscpack. >>>>>> >>>>>> I think liblo might be a good reference for an oscpack TCP layer. >>>>>> Since >>>>>> we actually need the TCP support within oscpack itself, some code >>>>>> snippets might be helpful. My question was if somebody had >>>>>> done some >>>>>> work on TCP for oscpack in particular. >>>>>> >>>>>> best, >>>>>> Martin.K >>>>>> >>>>>> >>>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>>> Hello, >>>>>>> >>>>>>> There is a TCP implementation in LibLo. Since the last >>>>>>> version, it >>>>>>> now retains sessions instead of closing after sending a single >>>>>>> message. What I have _not_ done is thoroughly tested it against >>>>>>> other >>>>>>> TCP implementations, which would be an excellent step forward. >>>>>>> >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> >>>>>>> wrote: >>>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>>> there. i >>>>>>>> don't know how well separated the OSC part is from the rest >>>>>>>> of the >>>>>>>> programme, though. >>>>>>>> >>>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>>> >>>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>>> TCP, but >>>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>>> >>>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>>> transport >>>>>>>>>> methods to oscpack. >>>>>>>>>> >>>>>>>>>> I've read some threads on the topic, but I wasn't able to >>>>>>>>>> find >>>>>>>>>> any >>>>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>>>> ask if >>>>>>>>>> eventually someone already has done some work on that? >>>>>>>>>> >>>>>>>>>> best, >>>>>>>>>> Martin.K >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSC_dev mailing list >>>>>>>>>> OSC_dev@... >>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>>> --- >>>> >>>> Andy W. Schmeder >>>> andy [at] cnmat.berkeley.edu >>>> >>>> Programmer/Analyst II >>>> Research Group >>>> Center for New Music and Audio Technologies >>>> University of California at Berkeley >>>> http://cnmat.berkeley.edu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Roger Dannenberg
::
Rate this Message:
If you do not have a length count, you can either read one byte at a
time looking for a complete message, which is inefficient, or you can try to read a larger buffer, but since TCP is a byte stream protocol, you might block arbitrarily long until that many bytes have been received. This may be well-known, but since I didn't see it mentioned, it's important to note that with TCP, the sender can and will delay sending small messages in the interest of collecting multiple messages into one large network packet. Wikipedia says it well: "Applications that expect real time responses can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games expect that actions in the game are sent immediately, while the algorithm purposefully delays transmission, increasing latency <http://en.wikipedia.org/wiki/Latency> at the expense of bandwidth <http://en.wikipedia.org/wiki/Bandwidth>. For this reason applications with low-bandwidth time-sensitive transmissions typically use |TCP_NODELAY| to bypass the Nagle delay." Some time ago, there was an argument that UDP gave you low latency and networks rarely drop data anyway. I argued that when things are working well, networks do not drop data, TCP acknowledgements piggy-back on other messages, and both the time delay and computational complexity for TCP are only slightly worse than UDP. The difference is that when things are broken, TCP still delivers the data. The right behavior depends on the application, but I've been very happy with TCP, and I've had some very bad experiences with UDP. I would recommend TCP as a starting point. -Roger Sciss wrote: > supercollider and netutil use this specification of osc 1.0 : packet > size (int32), then the data. i think it is very useful for efficient > read-in to have this size. i don't see any advantage removing this > information. the tcp in supercollider is rock solid since years and i > think following this spec is a good thing. > > ciao, -sciss- > > > Am 13.08.2009 um 16:08 schrieb Stephen Sinclair: > > >> I think LibLo gives the length because of this note in the 1.0 spec >> (section OSC Packets): >> >> "In a stream-based protocol such as TCP, the stream should begin with >> an int32 giving the size of the first packet, followed by the contents >> of the first packet, followed by the size of the second packet, etc." >> >> I agree that using a 'raw' approach would be best if it can be done, >> although I guess the rationale is that sending the size initially can >> be useful for a program that needs to allocate a buffer before reading >> the data. >> >> Does anyone know offhand whether Max/MSP and Pd's mrpeach >> implementations handle this differently? >> >> Steve >> >> >> On Thu, Aug 13, 2009 at 3:24 AM, Martin >> Kaltenbrunner<modin@...> wrote: >> >>> Hey Steve, >>> I actually wanted to discuss this topic as well. >>> In my opinion, a OSC/TCP connection should just send the OSC data >>> without any other header or length information. The receiver then can >>> take care of the proper segmentation, when looking at the incoming >>> data >>> stream OSC bundles can be identified accordingly. I guess this >>> should be >>> the "proper" way although I am not aware if there are some notes >>> on this >>> case in the OSC documentation. >>> >>> For TUIO we are already using OSC/TCP for Flash connections, where >>> this >>> raw OSC approach works quite fine. There is already a OSC/TUIO >>> ActionScript library by Dean North which does the job quite well. >>> Actually we are now working on a proper OSC/TCP implementation for >>> AS3 >>> for a new TUIO Flash library. >>> >>> There are already a few UDP/TCP gateways available for that purpose, >>> which just hand the UDP packet content to a TCP connection without >>> modification or metadata. Apart from Dean's touchgateway, Memo Akten >>> also created a very generic UDP/TCP bridge. >>> >>> http://www.touchgateway.com/ >>> http://code.google.com/p/udp-tcp-bridge/ >>> >>> so maybe we should talk about how to keep the TCP implementations in >>> sync to come to a compatible solution. >>> best, Martin.K >>> >>> >>> Am 13.08.09 03:19, schrieb Stephen Sinclair: >>> >>>> It just sends the length of the message, and then the message data. >>>> If the stream is interrupted, the message must be restarted. Isn't >>>> the whole point of TCP to be a reliable protocol? >>>> >>>> Steve >>>> >>>> >>>> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >>>> Schmeder<andy@...> wrote: >>>> >>>>> How does liblo frame the packets on TCP? >>>>> >>>>> We have been using double-ended SLIP on USB-serial and it has many >>>>> nice properties, such as clean recovery if the stream is >>>>> interrupted >>>>> and restarted. The recommendation given in the 1.0 spec is not so >>>>> great... >>>>> >>>>> >>>>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>>>> >>>>> >>>>>> Great! >>>>>> >>>>>> If you come up with any suggestions for improvements to the TCP >>>>>> layer >>>>>> in liblo (or find any bugs), please don't hesitate to make them. >>>>>> There may very well be details that need agreeing on, and I >>>>>> don't know >>>>>> of anyone seriously using the TCP implementation right now so it's >>>>>> better to change things if it needs it. >>>>>> >>>>>> thanks, >>>>>> Steve >>>>>> >>>>>> >>>>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>>>> Kaltenbrunner<modin@...> wrote: >>>>>> >>>>>>> Hello Steve (and others), >>>>>>> thanks for the hints on the various alternative OSC/TCP >>>>>>> implementations! >>>>>>> >>>>>>> Since I am planning to add TCP (and other alternative >>>>>>> transports) to >>>>>>> some multi-platform TUIO implementations, I will probably later >>>>>>> also go >>>>>>> on with adding this to JavaOSC and OSC.NET, which are used in >>>>>>> these >>>>>>> packages, just as oscpack. >>>>>>> >>>>>>> I think liblo might be a good reference for an oscpack TCP layer. >>>>>>> Since >>>>>>> we actually need the TCP support within oscpack itself, some code >>>>>>> snippets might be helpful. My question was if somebody had >>>>>>> done some >>>>>>> work on TCP for oscpack in particular. >>>>>>> >>>>>>> best, >>>>>>> Martin.K >>>>>>> >>>>>>> >>>>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> There is a TCP implementation in LibLo. Since the last >>>>>>>> version, it >>>>>>>> now retains sessions instead of closing after sending a single >>>>>>>> message. What I have _not_ done is thoroughly tested it against >>>>>>>> other >>>>>>>> TCP implementations, which would be an excellent step forward. >>>>>>>> >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>>>> there. i >>>>>>>>> don't know how well separated the OSC part is from the rest >>>>>>>>> of the >>>>>>>>> programme, though. >>>>>>>>> >>>>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>>>> >>>>>>>>> >>>>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>>>> TCP, but >>>>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>>>> >>>>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>>>> transport >>>>>>>>>>> methods to oscpack. >>>>>>>>>>> >>>>>>>>>>> I've read some threads on the topic, but I wasn't able to >>>>>>>>>>> find >>>>>>>>>>> any >>>>>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>>>>> ask if >>>>>>>>>>> eventually someone already has done some work on that? >>>>>>>>>>> >>>>>>>>>>> best, >>>>>>>>>>> Martin.K >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OSC_dev mailing list >>>>>>>>>>> OSC_dev@... >>>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSC_dev mailing list >>>>>>>>>> OSC_dev@... >>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>> --- >>>>> >>>>> Andy W. Schmeder >>>>> andy [at] cnmat.berkeley.edu >>>>> >>>>> Programmer/Analyst II >>>>> Research Group >>>>> Center for New Music and Audio Technologies >>>>> University of California at Berkeley >>>>> http://cnmat.berkeley.edu >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >>> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Sciss-3
::
Rate this Message:
hi roger,
i had similar experience: upd "basically works", but when OSC load becomes high, there is no guarantees and packets are definitely dropped, either by the OS or the client / server, i don't know, but it happens, even on "localhost". i have never had problems with data loss on TCP, so i regard it a safer solution, and i have never seen that there was any significantly increased latency. in fact, if the server is not able to handle all the incoming TCP, the client might be blocked automatically, which is, despite "realtime" obligations, usually favourable. for constant-rate traffic, like a sensor- interface, i see no advantage using TCP over UDP, but for inter- application communication, yes. cheers, -sciss- Am 13.08.2009 um 16:43 schrieb Roger Dannenberg: > If you do not have a length count, you can either read one byte at a > time looking for a complete message, which is inefficient, or you can > try to read a larger buffer, but since TCP is a byte stream protocol, > you might block arbitrarily long until that many bytes have been > received. > > This may be well-known, but since I didn't see it mentioned, it's > important to note that with TCP, the sender can and will delay sending > small messages in the interest of collecting multiple messages into > one > large network packet. Wikipedia says it well: "Applications that > expect > real time responses can react poorly with Nagle's algorithm. > Applications such as networked multiplayer video games expect that > actions in the game are sent immediately, while the algorithm > purposefully delays transmission, increasing latency > <http://en.wikipedia.org/wiki/Latency> at the expense of bandwidth > <http://en.wikipedia.org/wiki/Bandwidth>. For this reason applications > with low-bandwidth time-sensitive transmissions typically use > |TCP_NODELAY| to bypass the Nagle delay." > > Some time ago, there was an argument that UDP gave you low latency and > networks rarely drop data anyway. I argued that when things are > working > well, networks do not drop data, TCP acknowledgements piggy-back on > other messages, and both the time delay and computational > complexity for > TCP are only slightly worse than UDP. The difference is that when > things > are broken, TCP still delivers the data. The right behavior depends on > the application, but I've been very happy with TCP, and I've had some > very bad experiences with UDP. I would recommend TCP as a starting > point. > > -Roger > > Sciss wrote: >> supercollider and netutil use this specification of osc 1.0 : packet >> size (int32), then the data. i think it is very useful for efficient >> read-in to have this size. i don't see any advantage removing this >> information. the tcp in supercollider is rock solid since years and i >> think following this spec is a good thing. >> >> ciao, -sciss- >> >> >> Am 13.08.2009 um 16:08 schrieb Stephen Sinclair: >> >> >>> I think LibLo gives the length because of this note in the 1.0 spec >>> (section OSC Packets): >>> >>> "In a stream-based protocol such as TCP, the stream should begin >>> with >>> an int32 giving the size of the first packet, followed by the >>> contents >>> of the first packet, followed by the size of the second packet, >>> etc." >>> >>> I agree that using a 'raw' approach would be best if it can be done, >>> although I guess the rationale is that sending the size initially >>> can >>> be useful for a program that needs to allocate a buffer before >>> reading >>> the data. >>> >>> Does anyone know offhand whether Max/MSP and Pd's mrpeach >>> implementations handle this differently? >>> >>> Steve >>> >>> >>> On Thu, Aug 13, 2009 at 3:24 AM, Martin >>> Kaltenbrunner<modin@...> wrote: >>> >>>> Hey Steve, >>>> I actually wanted to discuss this topic as well. >>>> In my opinion, a OSC/TCP connection should just send the OSC data >>>> without any other header or length information. The receiver >>>> then can >>>> take care of the proper segmentation, when looking at the incoming >>>> data >>>> stream OSC bundles can be identified accordingly. I guess this >>>> should be >>>> the "proper" way although I am not aware if there are some notes >>>> on this >>>> case in the OSC documentation. >>>> >>>> For TUIO we are already using OSC/TCP for Flash connections, where >>>> this >>>> raw OSC approach works quite fine. There is already a OSC/TUIO >>>> ActionScript library by Dean North which does the job quite well. >>>> Actually we are now working on a proper OSC/TCP implementation for >>>> AS3 >>>> for a new TUIO Flash library. >>>> >>>> There are already a few UDP/TCP gateways available for that >>>> purpose, >>>> which just hand the UDP packet content to a TCP connection without >>>> modification or metadata. Apart from Dean's touchgateway, Memo >>>> Akten >>>> also created a very generic UDP/TCP bridge. >>>> >>>> http://www.touchgateway.com/ >>>> http://code.google.com/p/udp-tcp-bridge/ >>>> >>>> so maybe we should talk about how to keep the TCP >>>> implementations in >>>> sync to come to a compatible solution. >>>> best, Martin.K >>>> >>>> >>>> Am 13.08.09 03:19, schrieb Stephen Sinclair: >>>> >>>>> It just sends the length of the message, and then the message >>>>> data. >>>>> If the stream is interrupted, the message must be restarted. >>>>> Isn't >>>>> the whole point of TCP to be a reliable protocol? >>>>> >>>>> Steve >>>>> >>>>> >>>>> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >>>>> Schmeder<andy@...> wrote: >>>>> >>>>>> How does liblo frame the packets on TCP? >>>>>> >>>>>> We have been using double-ended SLIP on USB-serial and it has >>>>>> many >>>>>> nice properties, such as clean recovery if the stream is >>>>>> interrupted >>>>>> and restarted. The recommendation given in the 1.0 spec is >>>>>> not so >>>>>> great... >>>>>> >>>>>> >>>>>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>>>>> >>>>>> >>>>>>> Great! >>>>>>> >>>>>>> If you come up with any suggestions for improvements to the TCP >>>>>>> layer >>>>>>> in liblo (or find any bugs), please don't hesitate to make them. >>>>>>> There may very well be details that need agreeing on, and I >>>>>>> don't know >>>>>>> of anyone seriously using the TCP implementation right now so >>>>>>> it's >>>>>>> better to change things if it needs it. >>>>>>> >>>>>>> thanks, >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>>>>> Kaltenbrunner<modin@...> wrote: >>>>>>> >>>>>>>> Hello Steve (and others), >>>>>>>> thanks for the hints on the various alternative OSC/TCP >>>>>>>> implementations! >>>>>>>> >>>>>>>> Since I am planning to add TCP (and other alternative >>>>>>>> transports) to >>>>>>>> some multi-platform TUIO implementations, I will probably later >>>>>>>> also go >>>>>>>> on with adding this to JavaOSC and OSC.NET, which are used in >>>>>>>> these >>>>>>>> packages, just as oscpack. >>>>>>>> >>>>>>>> I think liblo might be a good reference for an oscpack TCP >>>>>>>> layer. >>>>>>>> Since >>>>>>>> we actually need the TCP support within oscpack itself, some >>>>>>>> code >>>>>>>> snippets might be helpful. My question was if somebody had >>>>>>>> done some >>>>>>>> work on TCP for oscpack in particular. >>>>>>>> >>>>>>>> best, >>>>>>>> Martin.K >>>>>>>> >>>>>>>> >>>>>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> There is a TCP implementation in LibLo. Since the last >>>>>>>>> version, it >>>>>>>>> now retains sessions instead of closing after sending a single >>>>>>>>> message. What I have _not_ done is thoroughly tested it >>>>>>>>> against >>>>>>>>> other >>>>>>>>> TCP implementations, which would be an excellent step forward. >>>>>>>>> >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>>>>> there. i >>>>>>>>>> don't know how well separated the OSC part is from the rest >>>>>>>>>> of the >>>>>>>>>> programme, though. >>>>>>>>>> >>>>>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>>>>> TCP, but >>>>>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>>>>> >>>>>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>>>>> transport >>>>>>>>>>>> methods to oscpack. >>>>>>>>>>>> >>>>>>>>>>>> I've read some threads on the topic, but I wasn't able to >>>>>>>>>>>> find >>>>>>>>>>>> any >>>>>>>>>>>> specific code yet. Before we start from scratch, I'd >>>>>>>>>>>> like to >>>>>>>>>>>> ask if >>>>>>>>>>>> eventually someone already has done some work on that? >>>>>>>>>>>> >>>>>>>>>>>> best, >>>>>>>>>>>> Martin.K >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OSC_dev mailing list >>>>>>>>>>>> OSC_dev@... >>>>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OSC_dev mailing list >>>>>>>>>>> OSC_dev@... >>>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSC_dev mailing list >>>>>>>>>> OSC_dev@... >>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>> --- >>>>>> >>>>>> Andy W. Schmeder >>>>>> andy [at] cnmat.berkeley.edu >>>>>> >>>>>> Programmer/Analyst II >>>>>> Research Group >>>>>> Center for New Music and Audio Technologies >>>>>> University of California at Berkeley >>>>>> http://cnmat.berkeley.edu >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Martin Kaltenbrunner
::
Rate this Message:
OK, thanks for pointing that out, and sorry that I had overlooked this
detail before. In that case, I will make sure that the new TCP implementations will follow that approach, adding the additional length info. I will also talk to the developers of the UDP/TCP gateways to update their tools accordingly, so they can be used as generic OSC tools as well. best, Martin.K Am 13.08.09 16:08, schrieb Stephen Sinclair: > I think LibLo gives the length because of this note in the 1.0 spec > (section OSC Packets): > > "In a stream-based protocol such as TCP, the stream should begin with > an int32 giving the size of the first packet, followed by the contents > of the first packet, followed by the size of the second packet, etc." > > I agree that using a 'raw' approach would be best if it can be done, > although I guess the rationale is that sending the size initially can > be useful for a program that needs to allocate a buffer before reading > the data. > > Does anyone know offhand whether Max/MSP and Pd's mrpeach > implementations handle this differently? > > Steve > > > On Thu, Aug 13, 2009 at 3:24 AM, Martin Kaltenbrunner<modin@...> wrote: >> Hey Steve, >> I actually wanted to discuss this topic as well. >> In my opinion, a OSC/TCP connection should just send the OSC data >> without any other header or length information. The receiver then can >> take care of the proper segmentation, when looking at the incoming data >> stream OSC bundles can be identified accordingly. I guess this should be >> the "proper" way although I am not aware if there are some notes on this >> case in the OSC documentation. >> >> For TUIO we are already using OSC/TCP for Flash connections, where this >> raw OSC approach works quite fine. There is already a OSC/TUIO >> ActionScript library by Dean North which does the job quite well. >> Actually we are now working on a proper OSC/TCP implementation for AS3 >> for a new TUIO Flash library. >> >> There are already a few UDP/TCP gateways available for that purpose, >> which just hand the UDP packet content to a TCP connection without >> modification or metadata. Apart from Dean's touchgateway, Memo Akten >> also created a very generic UDP/TCP bridge. >> >> http://www.touchgateway.com/ >> http://code.google.com/p/udp-tcp-bridge/ >> >> so maybe we should talk about how to keep the TCP implementations in >> sync to come to a compatible solution. >> best, Martin.K >> >> >> Am 13.08.09 03:19, schrieb Stephen Sinclair: >>> It just sends the length of the message, and then the message data. >>> If the stream is interrupted, the message must be restarted. Isn't >>> the whole point of TCP to be a reliable protocol? >>> >>> Steve >>> >>> >>> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >>> Schmeder<andy@...> wrote: >>>> How does liblo frame the packets on TCP? >>>> >>>> We have been using double-ended SLIP on USB-serial and it has many >>>> nice properties, such as clean recovery if the stream is interrupted >>>> and restarted. The recommendation given in the 1.0 spec is not so >>>> great... >>>> >>>> >>>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>>> >>>>> Great! >>>>> >>>>> If you come up with any suggestions for improvements to the TCP layer >>>>> in liblo (or find any bugs), please don't hesitate to make them. >>>>> There may very well be details that need agreeing on, and I don't know >>>>> of anyone seriously using the TCP implementation right now so it's >>>>> better to change things if it needs it. >>>>> >>>>> thanks, >>>>> Steve >>>>> >>>>> >>>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>>> Kaltenbrunner<modin@...> wrote: >>>>>> Hello Steve (and others), >>>>>> thanks for the hints on the various alternative OSC/TCP >>>>>> implementations! >>>>>> >>>>>> Since I am planning to add TCP (and other alternative transports) to >>>>>> some multi-platform TUIO implementations, I will probably later >>>>>> also go >>>>>> on with adding this to JavaOSC and OSC.NET, which are used in these >>>>>> packages, just as oscpack. >>>>>> >>>>>> I think liblo might be a good reference for an oscpack TCP layer. >>>>>> Since >>>>>> we actually need the TCP support within oscpack itself, some code >>>>>> snippets might be helpful. My question was if somebody had done some >>>>>> work on TCP for oscpack in particular. >>>>>> >>>>>> best, >>>>>> Martin.K >>>>>> >>>>>> >>>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>>> Hello, >>>>>>> >>>>>>> There is a TCP implementation in LibLo. Since the last version, it >>>>>>> now retains sessions instead of closing after sending a single >>>>>>> message. What I have _not_ done is thoroughly tested it against >>>>>>> other >>>>>>> TCP implementations, which would be an excellent step forward. >>>>>>> >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> wrote: >>>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>>> there. i >>>>>>>> don't know how well separated the OSC part is from the rest of the >>>>>>>> programme, though. >>>>>>>> >>>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>>> >>>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>>> TCP, but >>>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>>> >>>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>>> transport >>>>>>>>>> methods to oscpack. >>>>>>>>>> >>>>>>>>>> I've read some threads on the topic, but I wasn't able to find >>>>>>>>>> any >>>>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>>>> ask if >>>>>>>>>> eventually someone already has done some work on that? >>>>>>>>>> >>>>>>>>>> best, >>>>>>>>>> Martin.K >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSC_dev mailing list >>>>>>>>>> OSC_dev@... >>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>>> --- >>>> >>>> Andy W. Schmeder >>>> andy [at] cnmat.berkeley.edu >>>> >>>> Programmer/Analyst II >>>> Research Group >>>> Center for New Music and Audio Technologies >>>> University of California at Berkeley >>>> http://cnmat.berkeley.edu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>> >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >> > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Matt Wright-6
::
Rate this Message:
There's another argument against "raw" OSC over TCP: non-bundle
messages do not encode their own length. If a message has type tags then you can laboriously read each one, adding up the sizes for the ones with fixed sizes. If the message has any variable-length arguments such as blobs then you have to parse almost the entire message before you know the message size. Even worse, if a message lacks type tags, there's absolutely no way to know how long it is. The original OSC (pre-typetags) completely relied on the transport layer (i.e., UDP) informing the receiving application about the byte count of the message. I hope there are no longer any non-type-tag OSC implementations (!) but if there are, "raw" OSC over TCP would be doomed. -Matt On Aug 13, 2009, at 7:54 AM, Martin Kaltenbrunner wrote: > OK, thanks for pointing that out, and sorry that I had overlooked this > detail before. In that case, I will make sure that the new TCP > implementations will follow that approach, adding the additional > length > info. I will also talk to the developers of the UDP/TCP gateways to > update their tools accordingly, so they can be used as generic OSC > tools > as well. > > best, > Martin.K > > > > Am 13.08.09 16:08, schrieb Stephen Sinclair: >> I think LibLo gives the length because of this note in the 1.0 spec >> (section OSC Packets): >> >> "In a stream-based protocol such as TCP, the stream should begin with >> an int32 giving the size of the first packet, followed by the >> contents >> of the first packet, followed by the size of the second packet, etc." >> >> I agree that using a 'raw' approach would be best if it can be done, >> although I guess the rationale is that sending the size initially can >> be useful for a program that needs to allocate a buffer before >> reading >> the data. >> >> Does anyone know offhand whether Max/MSP and Pd's mrpeach >> implementations handle this differently? >> >> Steve >> >> >> On Thu, Aug 13, 2009 at 3:24 AM, Martin >> Kaltenbrunner<modin@...> wrote: >>> Hey Steve, >>> I actually wanted to discuss this topic as well. >>> In my opinion, a OSC/TCP connection should just send the OSC data >>> without any other header or length information. The receiver then >>> can >>> take care of the proper segmentation, when looking at the incoming >>> data >>> stream OSC bundles can be identified accordingly. I guess this >>> should be >>> the "proper" way although I am not aware if there are some notes >>> on this >>> case in the OSC documentation. >>> >>> For TUIO we are already using OSC/TCP for Flash connections, where >>> this >>> raw OSC approach works quite fine. There is already a OSC/TUIO >>> ActionScript library by Dean North which does the job quite well. >>> Actually we are now working on a proper OSC/TCP implementation for >>> AS3 >>> for a new TUIO Flash library. >>> >>> There are already a few UDP/TCP gateways available for that purpose, >>> which just hand the UDP packet content to a TCP connection without >>> modification or metadata. Apart from Dean's touchgateway, Memo Akten >>> also created a very generic UDP/TCP bridge. >>> >>> http://www.touchgateway.com/ >>> http://code.google.com/p/udp-tcp-bridge/ >>> >>> so maybe we should talk about how to keep the TCP implementations in >>> sync to come to a compatible solution. >>> best, Martin.K >>> >>> >>> Am 13.08.09 03:19, schrieb Stephen Sinclair: >>>> It just sends the length of the message, and then the message data. >>>> If the stream is interrupted, the message must be restarted. Isn't >>>> the whole point of TCP to be a reliable protocol? >>>> >>>> Steve >>>> >>>> >>>> On Wed, Aug 12, 2009 at 6:16 PM, Andy W. >>>> Schmeder<andy@...> wrote: >>>>> How does liblo frame the packets on TCP? >>>>> >>>>> We have been using double-ended SLIP on USB-serial and it has many >>>>> nice properties, such as clean recovery if the stream is >>>>> interrupted >>>>> and restarted. The recommendation given in the 1.0 spec is not so >>>>> great... >>>>> >>>>> >>>>> On Aug 12, 2009, at 9:04 AM, Stephen Sinclair wrote: >>>>> >>>>>> Great! >>>>>> >>>>>> If you come up with any suggestions for improvements to the TCP >>>>>> layer >>>>>> in liblo (or find any bugs), please don't hesitate to make them. >>>>>> There may very well be details that need agreeing on, and I >>>>>> don't know >>>>>> of anyone seriously using the TCP implementation right now so >>>>>> it's >>>>>> better to change things if it needs it. >>>>>> >>>>>> thanks, >>>>>> Steve >>>>>> >>>>>> >>>>>> On Wed, Aug 12, 2009 at 11:42 AM, Martin >>>>>> Kaltenbrunner<modin@...> wrote: >>>>>>> Hello Steve (and others), >>>>>>> thanks for the hints on the various alternative OSC/TCP >>>>>>> implementations! >>>>>>> >>>>>>> Since I am planning to add TCP (and other alternative >>>>>>> transports) to >>>>>>> some multi-platform TUIO implementations, I will probably later >>>>>>> also go >>>>>>> on with adding this to JavaOSC and OSC.NET, which are used in >>>>>>> these >>>>>>> packages, just as oscpack. >>>>>>> >>>>>>> I think liblo might be a good reference for an oscpack TCP >>>>>>> layer. >>>>>>> Since >>>>>>> we actually need the TCP support within oscpack itself, some >>>>>>> code >>>>>>> snippets might be helpful. My question was if somebody had >>>>>>> done some >>>>>>> work on TCP for oscpack in particular. >>>>>>> >>>>>>> best, >>>>>>> Martin.K >>>>>>> >>>>>>> >>>>>>> Am 12.08.09 17:05, schrieb Stephen Sinclair: >>>>>>>> Hello, >>>>>>>> >>>>>>>> There is a TCP implementation in LibLo. Since the last >>>>>>>> version, it >>>>>>>> now retains sessions instead of closing after sending a single >>>>>>>> message. What I have _not_ done is thoroughly tested it >>>>>>>> against >>>>>>>> other >>>>>>>> TCP implementations, which would be an excellent step forward. >>>>>>>> >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 12, 2009 at 7:15 AM, Sciss<contact@...> >>>>>>>> wrote: >>>>>>>>> p.s. and supercollider supports TCP, so you have some C code >>>>>>>>> there. i >>>>>>>>> don't know how well separated the OSC part is from the rest >>>>>>>>> of the >>>>>>>>> programme, though. >>>>>>>>> >>>>>>>>> Am 12.08.2009 um 13:13 schrieb Sciss: >>>>>>>>> >>>>>>>>>> netutil ( http://sourceforge.net/projects/netutil ) supports >>>>>>>>>> TCP, but >>>>>>>>>> that is java, i assume you are looking for C(++) code? >>>>>>>>>> >>>>>>>>>> Am 12.08.2009 um 11:13 schrieb Martin Kaltenbrunner: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> we are planning to add TCP support and other alternative >>>>>>>>>>> transport >>>>>>>>>>> methods to oscpack. >>>>>>>>>>> >>>>>>>>>>> I've read some threads on the topic, but I wasn't able to >>>>>>>>>>> find >>>>>>>>>>> any >>>>>>>>>>> specific code yet. Before we start from scratch, I'd like to >>>>>>>>>>> ask if >>>>>>>>>>> eventually someone already has done some work on that? >>>>>>>>>>> >>>>>>>>>>> best, >>>>>>>>>>> Martin.K >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OSC_dev mailing list >>>>>>>>>>> OSC_dev@... >>>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSC_dev mailing list >>>>>>>>>> OSC_dev@... >>>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OSC_dev mailing list >>>>>>>>> OSC_dev@... >>>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSC_dev mailing list >>>>>>>> OSC_dev@... >>>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> _______________________________________________ >>>>>>> OSC_dev mailing list >>>>>>> OSC_dev@... >>>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>>>> >>>>>> _______________________________________________ >>>>>> OSC_dev mailing list >>>>>> OSC_dev@... >>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>>> --- >>>>> >>>>> Andy W. Schmeder >>>>> andy [at] cnmat.berkeley.edu >>>>> >>>>> Programmer/Analyst II >>>>> Research Group >>>>> Center for New Music and Audio Technologies >>>>> University of California at Berkeley >>>>> http://cnmat.berkeley.edu >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSC_dev mailing list >>>>> OSC_dev@... >>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>>>> >>>> _______________________________________________ >>>> OSC_dev mailing list >>>> OSC_dev@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> _______________________________________________ >>> OSC_dev mailing list >>> OSC_dev@... >>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev >>> >> _______________________________________________ >> OSC_dev mailing list >> OSC_dev@... >> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Adrian Freed
::
Rate this Message:
OSC 1.1 specifies SLIP as the packet wrapping protocol for OSC over
byte-stream transports. The approach we originally suggested in OSC (with a preamble and count) is flawed. _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Sciss-3
::
Rate this Message:
well that has been in real-world use for years and proved flawless,
at least in the context i experienced. i don't think osc 1.1 should break compatibility here. if you need another transport, add it as another transport, serial cables or whatever is the target for SLIP. leave TCP transport as it is, or call the new one "TCP 2". 2c, -sciss- Am 13.08.2009 um 18:08 schrieb adrian@...: > The approach we originally suggested in OSC (with a preamble and > count) is > flawed. _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Jeff Koftinoff
::
Rate this Message:
Hmm...
In what way is a preamble and count flawed? Regards, jeffk On 2009-Aug-13, at 9:08 AM, adrian@... wrote: > OSC 1.1 specifies SLIP as the packet wrapping protocol for OSC over > byte-stream transports. > The approach we originally suggested in OSC (with a preamble and > count) is > flawed. > > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Adrian Freed
::
Rate this Message:
>well that has been in real-world use for years and proved flawless,
>at least in the context i experienced. i don't think osc 1.1 should >break compatibility here. if you need another transport, add it as >another transport, serial cables or whatever is the target for SLIP. >leave TCP transport as it is, or call the new one "TCP 2". > thanks for the feedback. The flaw I had in mind to avoid is in error prone serial transports and wireless situations because resynch is harder with protocols with counts. _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: oscpack TCP
by Jeff Koftinoff
::
Rate this Message:
Hi Adrian, I agree that SLIP is a good solution over serial links, but
not TCP. HTTP works just fine with prefix counts for keep-alive mode for instance. In addition, you may want to consider using PPP over serial links and/ or TCP because of the ability to use existing authentication systems. Regards, Jeff On 2009-Aug-13, at 10:48 AM, Adrian Freed wrote: >> well that has been in real-world use for years and proved flawless, >> at least in the context i experienced. i don't think osc 1.1 should >> break compatibility here. if you need another transport, add it as >> another transport, serial cables or whatever is the target for SLIP. >> leave TCP transport as it is, or call the new one "TCP 2". >> > thanks for the feedback. > The flaw I had in mind to avoid is in error prone serial transports > and wireless situations because resynch is harder with protocols > with counts. > _______________________________________________ > OSC_dev mailing list > OSC_dev@... > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
