Results 1 to 5 of 5

Thread: TCP Output Module

  1. #1
    Join Date
    Sep 2010
    Location
    Folsom, Ca
    Posts
    90
    Post Thanks / Like

    Default TCP Output Module

    I created an output module using TCP. Modeled after Generic Serial Output, this module creates a TCP Client that will connect to any TCP Server of your choosing or creation. You can simply download a TCP Server free online or from your phone app store to test. I'll include a simple TCP Server set to port 8085. All you need is an IP address and a port. Make sure your firewall isn't blocking you.

    The output format is simple and separated by a period.
    For example: Header.0.0.0.0.0.0.0.Footer

    My goal was to create this, release it, and see if it would be useful on a Raspberry Pi or the Beaglebone Black type of platform, wired or wireless.

    TCP is connection-oriented so it will be slower than UDP but the data will arrive at the destination, guaranteed and in the proper order. That is not the case with UDP. Decreasing the update interval will speed up your refresh rate.

    I've only tested on a Windows 10 64-bit PC and currently works with Vixen 3.0 3.3u2.
    Place TCPtaco.dll in: C:\Program Files\Vixen\Modules\Controller
    Use the included TCP Server to test.

    UDP module coming soon. Looking forward to feedback.
    Happy Blinking
    Attached Files Attached Files

  2. #2
    Join Date
    Dec 2014
    Location
    Florida
    Posts
    909
    Post Thanks / Like

    Default Re: TCP Output Module

    Thanks for sharing, I'm guessing this was a project just because you wanted to?


    That is not the case with UDP.
    You sound a bit wound up over the textbook rules of traffic. We all use UDP over local networks. Order is never an issue because of the relatively long time between packets, and (usually) having no routers between source and destination. And the UDP application protocol we use has the provisions for dealing with or detecting packet order at the Application layer instead of the Transport layer. But except for the ESPixelStick I don't think anyone really pays attention, because it isn't an issue.

    Plus, in our streaming light application, we'd rather drop a packet and move on, then tie up our playback and controllers devices in a loop trying to do re-transmit until reception is verified like TCP will do on degraded links. I actually take this one step further an use Multicast UDP for most of my universes so that my WiFi Access Point won't attempt to verify reception of UDP packets at the Data Link Layer and re-transmit.

    see if it would be useful on a Raspberry Pi or the Beaglebone Black type of platform, wired or wireless.
    We have a standard adopted by the entire community already, with millions of hours of use and reliability. sACN or e1.31. It's what is used now for streaming to/from a "Raspberry Pi or the Beaglebone Black"
    [url]www.billporter.info[/url]
    2014 Christmas: 1 Channel; a new house and a crazy plan.
    2015 [url="https://www.youtube.com/playlist?list=PLwnQkTJSld3WRF86Nfv099UZahf___A7i"]Halloween: 2500 Channels;[/url] 3 songs. [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3VVfgwM0nxDebdwI__rQZ9Z"]Christmas: 4500 Channels[/URL]; 6 songs. Custom Wifi Pixel/Renard Controllers
    2016 [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3UKHXDhmKhdheaJBOFgJ5IL"]Halloween: 6500 Channels;[/URL] 4 songs. [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3Uk21zJ3QHeHEMe1XzJOTSr"]Christmas: 11,000 Channels;[/URL] 4 songs.

  3. #3
    Join Date
    Sep 2010
    Location
    Folsom, Ca
    Posts
    90
    Post Thanks / Like

    Default Re: TCP Output Module

    Thank you for the reply! I did do this simply because I wanted to. I really enjoy learning how things work and creating on my own. I'm not wound up at all about the rules of traffic. If I didn't write that TCP info someone would simply say, "this is stupid UDP will be quicker". I'm going to end all that now and say you and everyone are right. You win. In my opinion sending packets from your house/garage to your front yard is such a trivial distance for me speed isn't an issue. The point is moot anyway, as I pointed out in my original post I'll do the same this month with UDP.



    Quote Originally Posted by madsci1016 View Post
    We have a standard adopted by the entire community already, with millions of hours of use and reliability. sACN or e1.31. It's what is used now for streaming to/from a "Raspberry Pi or the Beaglebone Black"
    This is interesting to me. Maybe it's my ignorance or living/working around silicon valley, I think different. For myself, nothing in life is standard. Especially hardware/software. I look at things as constantly changing. I remember when the blackberry/crackberry was the "adopted standard" cell phone. Gave you everything you could want. Suddenly, some almost bankrupt company called Apple who had nothing to do with cell phones released an iPhone. It's the "adopted standard" you go buy a car at a dealership. A company called Tesla that refuses that model has over 400,000 reservations for a car that isn't even out yet! Model 3 has zero consumer "hours of use and reliability." Can Ford say that? Chevy? And that is a vehicle that can kill you, not Christmas lights. "We" on this forum doesn't include me I guess. The purpose of this whole subforum in this community is to develop new outputs I thought?

    Yes those are great output modules and mine will never compare. They probably do more. You are right. If only one person tries mine I'll be thrilled. For end users mine won't make a difference.


    For the people who need help to code: If you don't want to worry about universes or weird channel limits (mine doesn't have that) I invite you to try my output module. Again, I have no weird channel limits or universes (whatever that is). It's generic, it's simple, you only need an IP, a port and number of channels. You can have thousands more than 512 channels with no loss of refresh rate. Or spread it out and keep it small, you can use more than one TCP output at the same time, just change the port number. On the hardware side you can stuff the values, even without headers or footers, into an array in only two lines of code:

    Code:
    c#
    string s = [input.TCP.string.separated.by.periods];
    string[] values = s.Split('.');
    
    //Boom! That's all it takes
    I'm really interested in user feedback about how I can help and improve the module. UDP is coming. OR is it Winter is coming? Blinky Blinky is coming? LoL

  4. #4
    Join Date
    Dec 2014
    Location
    Florida
    Posts
    909
    Post Thanks / Like

    Default Re: TCP Output Module

    Quote Originally Posted by Gorak View Post
    I think different. For myself, nothing in life is standard.
    This forum and community is a made up of a few dozen technical experts that create software/hardware/technologies that make it easier for the larger majority to create large artistic light displays without the need to become experts themselves. They don't need to have memorized PIC registers but they can use a Renard dimmer board to control lights. They don't need to understand the OSI networking model but they can stream large amounts of data from a Raspberry Pi to a pixel controller. They can do this with the free or reasonable priced technology created for this purpose. They people who created this technology didn't do it to make a profit. If they did they'd be working for Light-o-Rama. They did it because they like enabling other people.

    But the technical experts that created this technology don't want to spend the rest of their free time providing tech support. There is a way to reduce the complexity of support for the community, it's through standardization. That's the (literal) reason the standard dimmer hardware, the Renard SS dimmer, was created. SS stands for "Standardized Series". It's been the same design for years. Sure, we could make improvements. We could have integrated WiFi onboard, we could have higher density outputs, we could have a kitchen sink by now. But all those improvements would only make it harder to support people who want to use it. It would make it harder for us to identify problems people might have through this forum. By keeping it the same design, end users have better chances of success, we aren't stuck writing new revision of a user manual every change, and we are able to support users and identify issues much quicker.

    Now some people, like yourself and even I sometimes, like designing new technologies just because we like to swing the hammer we know and love. They don't fill a need by the community and don't offer anything new. And that's fine, and it's even fine to share. I have my own version of Sporadic's ESPixelStick, and I even share it online. But anyone that asks me about it or wants to buy one from me, I send to to Sporadic's group buys instead. Because it's better for the community that his design be the standard for that tool.

    Yes, this sub forum is to discus output modules for Vixen. And it's awesome your are sharing your new TCP method. But the potential outcome of your wording is what causes concern.

    My goal was to create this, release it, and see if it would be useful on a Raspberry Pi or the Beaglebone Black type of platform, wired or wireless.

    TCP is connection-oriented so it will be slower than UDP but the data will arrive at the destination, guaranteed and in the proper order. That is not the case with UDP.
    A few dozen people who are not tech experts may read this. They may incorrectly infer that TCP is superior to the UDP based protocol the community uses and believe they will be ahead of the game by using your output module. They may also infer incorrectly that there is no other way to stream to a "a Raspberry Pi or the Beaglebone Black type of platform". When they run into issues using it and you aren't around to support them, the Vixen Developers on this forum will now have to spend time working with them to get the issues resolved, probably by educating them not to use you module. Time for them they might not have had to spend had these users simply used the 'standard' output modules.

    Better wording, one they would still allow you to share your project without the potential risk stated above, would have been something along the lines of

    I created an output module for Vixen using TCP. I wanted to try a design that used a connection based approaching instead of streaming UDP packets. I'm posting it here for anyone interested in trying it out. If you don't know the difference between stream and packet based protocols, I suggest you stick with the standard Vixen outputs.
    Now for anyone that wants to be educated, because there are people that lurk the forums just to learn things, the protocol 'standard' for this community to stream light data is called sACN or e1.31. It's the same thing, different names. The wiki goes pretty far in depth explaining it. Yes, it's UDP based and in most applications UDP is frowned upon because data order and reception integrity is considered most important. We don't want web pages loading out of order or missing parts. But in our applications, like with streaming video and VOIP, latency is more important than data order and reception integrity. Data order is still somewhat important, which is why sACN has it's own method to detect out of order packets and drop them, but latency is still most important. This is why 'we' use UDP to stream blinky lights data. It's why there hasn't been a TCP output module for Vixen until now.

    If you don't want to worry about universes or weird channel limits (mine doesn't have that) I invite you to try my output module. Again, I have no weird channel limits or universes (whatever that is).
    Again, wording is key. I invite you to spend some more time learning about sACN, why it has universes and where the the 512 channel limit comes from. You might be more cautious about trying to turn people away from it if you do.
    Last edited by madsci1016; 03-12-2017 at 01:31 PM.
    [url]www.billporter.info[/url]
    2014 Christmas: 1 Channel; a new house and a crazy plan.
    2015 [url="https://www.youtube.com/playlist?list=PLwnQkTJSld3WRF86Nfv099UZahf___A7i"]Halloween: 2500 Channels;[/url] 3 songs. [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3VVfgwM0nxDebdwI__rQZ9Z"]Christmas: 4500 Channels[/URL]; 6 songs. Custom Wifi Pixel/Renard Controllers
    2016 [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3UKHXDhmKhdheaJBOFgJ5IL"]Halloween: 6500 Channels;[/URL] 4 songs. [URL="https://www.youtube.com/playlist?list=PLwnQkTJSld3Uk21zJ3QHeHEMe1XzJOTSr"]Christmas: 11,000 Channels;[/URL] 4 songs.

  5. #5
    Join Date
    Sep 2010
    Location
    Folsom, Ca
    Posts
    90
    Post Thanks / Like

    Default Re: TCP Output Module

    I've never experienced anything like this on this forum. I'm in the technical section. I'm in module development, intended for people like me. I'm asking for help and feedback but instead you and I are in some weird semi-flame war. I was hoping for feedback to make this module better. At least use it and tell me it isn't working or something useful to help.

    I'm sharing an idea, just like the first, well second post, of the first sticky this subforum asks for. If this is a burden then the module development would not exist. Please help me out? 5 posts not talking about what I need in this thread are enough. Actually use it and help me improve or at least stop commenting or privately message me.

    Thank You

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •