Home› AMX Forum› NetLinx Studio

Listening to UDP on a Netlinx

ThorleifurThorleifur Junior Member
in NetLinx Studio
Hi mates
So I got a problem listening to some UDP strings. These UTP strings are streaming ACN which is a DMX protocol over Ethernet and if somebody is interested to know something about it, then here you go (http://openacn.engarts.com/index.html) .
I have done UDP connections on a number of projects and it has always been a walk in the park. Never any hassles until now. What I am not doing now is connecting to one source exactly, but I am listening to a cloud (239.255.0.1). I can connect to the udp-address of the cloud but I get no strings back (to the buffer) even though Wireshark is going nuts with information.
I am not seeing what I am doing wrong. Might be something simple, so I ask you guys to run your eyes over this and see if I am missing something. Everything is run over an open switch so no problems on the network end.
I use ACNviewer to send the strings onto the network (http://sacnview.sourceforge.net/)
PROGRAM_NAME='ACN'

DEFINE_DEVICE

dvACNCLIENT  = 0:5:0

DEFINE_CONSTANT

lACNPORT = 5568

DEFINE_VARIABLE

VOLATILE INTEGER nCOUNT
VOLATILE INTEGER nCLIENTON
VOLATILE CHAR cCLIENTBUFFER[1000]
CHAR cADDRESS[15] = '239.255.0.1'

DEFINE_START

CREATE_BUFFER dvACNCLIENT,cCLIENTBUFFER
IP_CLIENT_OPEN(dvACNCLIENT.PORT,cADDRESS,lACNPORT,IP_UDP_2WAY)

DEFINE_EVENT

DATA_EVENT [dvACNCLIENT]
    {
    ONLINE:
	{
	nCLIENTON = TRUE
	}
    OFFLINE:
	{
	nCLIENTON = FALSE
	WAIT 50
	    IP_CLIENT_OPEN (dvACNCLIENT.port,cADDRESS,lACNPORT,IP_UDP_2WAY)
	}
    STRING:
	{

	   SEND_STRING 0,cCLIENTBUFFER
	   IF (FIND_STRING(DATA.TEXT,0,1))
	   {
		SEND_STRING 0,"'FOUND SOMETHING'"
	   }

	}
    ONERROR:
	{
	SWITCH (DATA.NUMBER)
	{
	CASE 9: // Socket closed in response to IP_CLIENT_CLOSE
	CASE 17: // String was sent to closed socket
	    {}
	DEFAULT:  // ALL OTHER ERRORS. May want to retry connection
	    {
	    WAIT 50
		IP_CLIENT_OPEN (dvACNCLIENT.port,cADDRESS,lACNPORT,IP_UDP_2WAY)
	    }
	}
    }
}



DEFINE_PROGRAM



Thanks
· Share on FacebookShare on Twitter

Comments

  • jjamesjjames AMX Sustaining Engineer
    If it's a UDP broadcast (which it appears to be from the screenshot of the WS - see the second line), as opposed to UDP control, you should look at IP_MC_SERVER_OPEN.
    · Share on FacebookShare on Twitter
  • ericmedleyericmedley Senior Member - 3709 Posts
    Is this a multi-cast stream?
    · Share on FacebookShare on Twitter
  • John NagyJohn Nagy CineTouch Product Manager
    UDP is implicitly multicast; more precisely, broadcast, endpoint agnostic. Anyone or no one may listen.
    · Share on FacebookShare on Twitter
  • ThorleifurThorleifur Junior Member
    I worked...

    In all my years of programming I have never even heard of IP_MC_SERVER_OPEN. But it works now and I can go on and manupulate the string.

    I just knew it was something simple.

    Thanks jjames :)

    Yes, it is a Multicast stream as John Nagy says.
    · Share on FacebookShare on Twitter
  • jweatherjweather Junior Member
    John Nagy wrote: »
    UDP is implicitly multicast; more precisely, broadcast, endpoint agnostic. Anyone or no one may listen.

    UDP has no transmission control, thus your packets may fall on the floor without you noticing if there's no listener. However, it's not any more implicitly broadcast than TCP is. Switches and routers are going to route your UDP packets toward their destination IP address just like they will with TCP packets. Broadcast means they will flood an entire subnet. Multicast means a session protocol is used to notify switches and routers of which multicast groups you are interested in, and IP addresses in the 224.-239. range. Calling IP_MC_SERVER_OPEN causes your master to send a session subscribe message for the multicast group (= IP address) you are interested in. http://en.wikipedia.org/wiki/IP_multicast
    · Share on FacebookShare on Twitter
Sign In or Register to comment.