Home AMX User Forum NetLinx Studio

connection refused

Hi all, I'm working on project with 20 Barix Exstreamer auido decoders and I would like to get progress feedback from each unit. I can get feedback from one unit at a time, but if I try more than one I get a connection refused error on all but the first one. I defined 20 ports for feedback, is it possible that there is a limit of one open port at a time?

Comments

  • viningvining Posts: 4,368
    Netlinx is supposed to ba able to handle 200 simultaneous IP socket connections so I doubt that is the problem. Show some code.
  • WjrichWjrich Posts: 8
    		 
    SEND_STRING Exstreamers[actTP],"'GET /rc.cgi?v=8&S=http://',webSrvAddress,'/',
         MP3_Files[actTP][1][1],'-',MP3_Files[actTP][1][2],'-',MP3_Files[actTP][pLANGUAGE][3],
         '.mp3',' HTTP/1.1',13,10,'Host: ',Exstreamer_address,13,10,13,10"				
    wait 12 
       {
          IP_CLIENT_OPEN(Exstreamers[actTP].PORT, Exstreamer_address, httpPort , 1)
          wait 5 SEND_STRING Exstreamers[actTP],"'GET /rc.cgi?L=getstate.ack HTTP/1.1',13,10,'Host: ',Exstreamer_address,13,10,13,10"				
          wait 10 IF(FIND_STRING(Exstreamer_Buffer[actTP],'<STATE>1</STATE>',1)) //Write log  only if play command accepted
    	{
    	     WriteAppLog ("MP3_Files[actTP][1][1],'-',MP3_Files[actTP][1][2],'-',MP3_Files[actTP][pLANGUAGE][3],'.mp3'")
    	     PULSE[VIRTUALS[actTP],9]
    	     WAIT 15
    	      {
    		wait 2 result1=IP_CLIENT_OPEN(Exstreamers[actTP].PORT, Exstreamer_address, httpPort , 1)
    		wait 5 SEND_STRING Exstreamers[actTP],"'GET /rc.cgi?c=66&L=getstate.ack HTTP/1.1',13,10,'Host: ',Exstreamer_address,13,10,13,10"
    		[B]wait 2 result2=IP_CLIENT_OPEN(FEEDBACKS[actTP].PORT, Exstreamer_address, 12302 ,1)[/B]	      
                          }
    	}   
        }
    

    After a song is played, I send a command to check the state. If it's playing then a command is sent to the device to enable progress feedback on the tcp command interface, last IP_CLIENT_OPENT is sent and thats where I get the connection refused error if feedback is already being sent from another device.
  • viningvining Posts: 4,368
    I don't like the waits in your code. These are HTTP connections and I wouldn't count on waits to time the connection since sometimes they take longer to drop and since you're not using IP_CLIENT_CLOSE to force the port closed it may still be connected after the wait time is up and you attemp another connection. Even if you use the IP_CLIENT_CLOSE the master may still consider it online beyond the wait time.

    First I would create an array to track online/offline events for each port/connection you need and then I would also create array of queues to hold the strings you need to send for each connection. Then use timeline or a loop in define_program (behind a small wait to keep it form running on every pass) to check your queues for traffic to send. If there's traffic to send and the online/offline status being tracked for that port is offline then call a function to do your ip_client_open for that port and when you get your online event trigger send your traffic and change you online/offline status to online. When the http server is done with your traffic it should automatically close the port and you'll get an offline event which you can use to reset your online/offline flag. This way you will only open a port when it is closed and it will automatically re-connect if you have more than one command in the queue every time the timeline event triggers or wait in define_progam expires. You can also put your function call in the offline event handler to immediately check the queue if you want to speeds things up..
  • DHawthorneDHawthorne Posts: 4,584
    There is a considerable delay between opening an IP connection and the connection going online. Likewise, there is also a considerable delay between closing one and it going offline. I imagine it's mainly housekeeping with the connections, but as Vin said, you can't rely on waits, and you can't depend on the timing being the same every instance. You definitely have to wait for online/offline events and base your commands on that.
  • WjrichWjrich Posts: 8
    So, I've tried an online/offline event using flags for each port and checking the flag before sending strings, but I still get a connection refused when one port is already recieving feedback. Just a thought, the port stays open the enitre time it's recieving feedback from the mp3 decoder and the decoder sends every second the progress in bytes. Could this be the problem??
  • viningvining Posts: 4,368
    You're using a seperate master port per decoder?

    Like:
    dvBarixAD_1             = 0:15:0 ;
    dvBarixAD_2             = 0:16:0 ;
    dvBarixAD_3             = 0:17:0 ;
    dvBarixAD_4             = 0:18:0 ;
    dvBarixAD_5             = 0:19:0 ;
    dvBarixAD_6             = 0:20:0 ;
    dvBarixAD_7             = 0:21:0 ;
    

    All the Barix decoders are physically different devices with different IP addresses correct?

    Are they all using the same internal port for connections? Can they be changed? If so try putting them on different ports. Of course you shouldn't have to since they are all appended to their ip address so there isn't a need for internal NAT.

    Post more code?
  • WjrichWjrich Posts: 8
    Yes all of the devices have thier own IP address and port.
    //Barix Exstreamers
    dvExstreamer1= 0:51:50
    dvExstreamer2= 0:52:50
    dvExstreamer3= 0:53:50
    dvExstreamer4= 0:54:50
    dvExstreamer5= 0:55:50
    dvExstreamer6= 0:56:50
    dvExstreamer7= 0:57:50
    dvExstreamer8= 0:58:50
    dvExstreamer9= 0:59:50
    dvExstreamer10= 0:60:50
    dvExstreamer11= 0:61:50
    dvExstreamer12= 0:62:50
    dvExstreamer13= 0:63:50
    dvExstreamer14= 0:64:50
    dvExstreamer15= 0:65:50
    dvExstreamer16= 0:66:50
    dvExstreamer17= 0:67:50
    dvExstreamer18= 0:68:50
    dvExstreamer19= 0:69:50
    dvExstreamer20= 0:70:50
    

    also each barix has a port for feedback since feedback is transmitted over port 12302, the TCP command interface.
    //FEEDBACK FOR EXSTREAMERS
    FdBack1=0:71:0
    FdBack2=0:72:0
    FdBack3=0:73:0
    FdBack4=0:74:0
    FdBack5=0:75:0
    FdBack6=0:76:0
    FdBack7=0:77:0
    FdBack8=0:78:0
    FdBack9=0:79:0
    FdBack10=0:80:0
    FdBack11=0:81:0
    FdBack12=0:82:0
    FdBack13=0:83:0
    FdBack14=0:84:0
    FdBack15=0:85:0
    FdBack16=0:86:0
    FdBack17=0:87:0
    FdBack18=0:88:0
    FdBack19=0:89:0
    FdBack20=0:90:0
    
  • Not sure if it has any bearing in this case, but in your Wait 15 statement those waits don't stack so the 1st and 3rd statement are executing at about the same time and the 2nd statement is executing shortly thereafter. The waits that you have seem unreliable so I agree that changing them out would be good, but just to test have you tried bracketing the waits encased in the Wait 15 statement like so...
    WAIT 15
    {
      wait 2
      {
    	 result1=IP_CLIENT_OPEN(Exstreamers[actTP].PORT, Exstreamer_address, httpPort , 1)
    	 wait 5
    	 {
    		SEND_STRING Exstreamers[actTP],"'GET /rc.cgi?c=66&L=getstate.ack HTTP/1.1',13,10,'Host: ',Exstreamer_address,13,10,13,10"
    		wait 2
    		{
    		  result2=IP_CLIENT_OPEN(FEEDBACKS[actTP].PORT, Exstreamer_address, 12302 ,1)	      
    		}
    	 }
      }
    }
    

    --John
  • jazzwyldjazzwyld Posts: 199
    Is the IP Address you're communicating to the same one that is communicating back to you? Or does the device have two seperate IP address. It looks as if you have different device numbers for feedback and string. Is that true?
  • jazzwyldjazzwyld Posts: 199
    Also where is [actTP] being populated? Is that the touch panel or should you have it

    Send_string Streamers[vstreamtocontrol[active touch panel]] ? Just trying to follow your array.
  • WjrichWjrich Posts: 8
    Each Exstremer has one IP, but yes I set up two ports for feedback. One for feedback via http port 80 and one via the TCP command interface port 12302. Actp is the array index of the exstreamer that triggers the event.
  • WjrichWjrich Posts: 8
    Thanks everyone for your help, I solved the problem., turns out it was more of an issue with the Barix device. In order to recieve feedback, the port connection must established before the mp3 begins playing, rather than before the get feedback command is sent to the device. Vining, I implemented your suggestion for using a queue and it works great, it's more reliabe and seems to execute faster. Thanks again.
Sign In or Register to comment.