TCP Connection to a Device Controller

Hello,
I need to write a standalone Java application that listens to some port, connects with the Device Controller, and interact with it over TCP. In the DC config file i got:
<Receiver id="rec1" description="First Receiver" protocol="TCP">
<OptionList>
<opt:Name>TCPReceiver</opt:Name>
<opt:Address>localhost:9999</opt:Address>
</OptionList>
On port 9999 i got a Java ServerSocket listening for incomming connections. But the Device Controller wont connect. It says:
Feb 26, 2008 5:27:49 PM ...cecontroller.messaging.XMLTransformer [Thread-2] Err
or: Error parsing message: com.inqmy.lib.xml.parser.ParserException: XMLParser:
No data allowed here:TYP (:main:, row:1, col:3)
Feb 26, 2008 5:27:49 PM ...icecontroller.messaging.TCPConnection [Thread-2] Deb
ug: Incoming message was not ok: TYPE:DE
..which isn't helping me much!
The other option is to have the Receiver configured for communication over HTTP, with POST method, but then it wont connect, too. Besides, i think with POST it will be much more complicated - having to parse all those HTTP headers and stuff that normal servers do.
Over TCP it will be much more simpler, if I could only connect. Can someone explain me or give me a link to what i need to do to connect to the Device Controller over TCP?
Thank you for your time.
Edited by: Veselin Somlev on Feb 26, 2008 5:29 PM

Hi,
just to clarify.
You do write a java application that connects to a device controller, correct ?
Actually, there is no SAPP AII involved in your landscape ?
Best regards
Michael

Similar Messages

TCP connection error when sending MODBUS commands to WAGO 750-881 controller after 113655 bytes of data have been sent

Hi all,
I am new to the world of labview and am attempting to build a VI which sends commands to a 750-881 WAGO controller at periodic intervals of 10ms.
To set each of the DO's of the WAGO at once I therefore attempt to send the Modbus fc15 command every 10ms using the standard Labview TCP write module.
When I run the VI it works for about a minute before I recieve an Error 56 message telling me the TCP connection has timed out. Thinking this strange, I decided to record the number of bytes sent via the TCP connection whilst running the program. In doing so I noticed that the connection broke after exactly 113655 Bytes of data had been sent each time.
Thinking that I may have been sending too many messages I increased the While-loop delay from 10ms to 20, 100 and 200 ms but the error remained. I also tried playing with the TCP connection timeout and the TCP write timeout but neither of these had any effect on the problem.
I cannot see why this error is occuring, as the program works perfectly up untill the 113655 Bytes mark.
I have attached a screenshot of the basic VI (simply showing a MODBUS command being sent every second) and of a more advanced VI (where I am able to control each DO of the WAGO manually by setting a frequency at which the DO should switch between ON and OFF).
If anybody has any ideas on where the problems lie, or what I could do to further debug the program this would be greatly appreciated.
Solved!
Go to Solution.
Attachments:
Basic_VI.png ‏84 KB
Expanded_VI.png ‏89 KB

AvdLinden wrote:
Hi ThiCop,
Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here).
I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is " -# + ").
As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved.
If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing.
Modbus TCP RTU is a binary protocol, as you show in your Basic VI, where you format the data stream using byte values. So you have to interprete the returned answer accordingly with the Modbus RTU spec in hand. Now what is most likely happening is that the connection gets hung after a while since you do NOT read the data the device sends as response to your commands. The TCP/IP stack buffers those bytes and at some point the internal buffers overflow and the connection is blocked by the stack. So adding the TCP Read at strategic places (usually after each write) is the proper solution for this. Is there any reason that you didn't use the NI provided Modbus TCP library?
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

TCP/IP Connecting with Real Time Controller

I have a host running Labview on a windows XP and a realtime embedded controller on a pxi chassis that acts as the server. When the realtime is started it automatically goes into listen mode and listens for a connection from the host. The host opens a connection. After a valid connection is open the Real-Time side goes into a TCP_Read and the host can then send commands that the real time processes and sends to the FPGA on the pxi-chassis.
Now the problem I'm having is how to handle the case when a TCP connection is lost. I can have the TCP_Read on the real-time error on a time out and then go into a listen mode but this isn't very logical because then the host will have to reconnect each time a time out occurs. So if I make the TCP_Read timeout be infinite and if the connection is lost (let's say I unplug the ethernet cable and re-plug it back in) then I cannot recover from this and the Real-time will need to be re-booted.
I've tried to send the Real-time into listen mode if the error code is other than a timeout error (code 56) and have it go back to TCP_read mode if it is a timeout error. But if the connection is lost by means of a physical way (such as me pulling the ethernet wire and plugging it back in) then the Real-Time never sees that the connection is invalid. The host on the other hand can detect it bc it will get an error when it's trying to write?
So my is:
Is there any way to prevent an infinite loop that needs a reboot and at the same time prevent the host from reconnecting every time there is a timeout?

Hi SJeane,
I apologize for taking so long to respond, but I wanted to test this on my end. In doing so, I realized that using the RT Reboot Controller.vi after the connection is lost does not work because the message to reboot cannot be relayed to the target without communication! Thus, to solve this problem, we have to approach it a different way. You mentioned that you tried programmatically clearing errors, but did you try to reestablish connection after clearing the errors? I tested this on my end with a FieldPoint controller, and the attached VIs resumed operation even after unplugging/replugging the Ethernet cable (no reboot). Will this solution work for you?
Peter K.
National Instruments
Attachments:
Reestablish.zip ‏39 KB

Opening and closing Multiple TCP connections issues

Hi all I am having an issue with the TCP VI’s and wondering if anyone has experienced this issue.
My application is required to scan 50-100 IP addresses (statically assigned) and discover if an Ethernet device is connect at that IP address. Currently I am able to achieve this by opening a TCP connection and testing the error cluster to determine if a timeout has occurred (no timeout error means Ethernet device available at the IP address). I then ensure that the TCP connections are closed.
The issue I am have is that I require a 1 second delay between the TCP open and the TCP close which significantly slows down the process. Without the 1 second delay the vi successfully connects to the device once then fails to make any TCP connect regardless of the time delay until the PC is reset.
If anyone has any advice I would be very grateful
David Barr
P.S. I have attached a simplified section of code showing this issue
Attachments:
TCP Open close issue.vi ‏15 KB

smercurio_fc wrote:
If I understand you correctly you want the time delay to be 1 second if there's a successful connection....
While I don't have a specific answer for this problem. I want to clarify for him. I believe the issue is, what if all connections ARE there? That means you keep returning a wait of 1 second 50-100 times so It takes 50-100 seconds just to initialize. I think the user is looking for a way to check for valid connections, but do so in such a way that eliminates the need for a wait which is greatly slowing things down.
CLA, LabVIEW Versions 2010-2013

Delete a Midi device controller - Logic Pro X

Hello,
I got problems with Midi device controller. I've installed (manually) the driver of the Axiom 49 (2nd Gen) which is not working well. I decided so to change with the Impulse 49 by Novation. The problems I got is that I cannot delete the Axiom 49 device from the ; Logic Pro X > Controller device > settings >Delete.... nothing happens. furthermore at each start of Logic, I got a warning that the device is not connected.
I tried to reset all settings Midi drivers in the preferences of Logic Pro X but even with no success.
Thank you in advance to give me a way to get rid of this problem.
Regards,
Thomas
LOGIC PRO X 10.0.5
Mac book pro : OS X 10.9.1

Feet1st.....
Typically you should do your research before you start throwing subs
Ummmm... maybe you should take your own advice?
I've seen this happen several times and in every case it relates to a specific driver installed and how it was installed..
It doesn't happen with other drivers.... which leads one to realize its probably not specifically a LP issue as such but more likely related to the specific driver itself....or a file/folder/User permissions issue..
Example.. I just went and deleted all my surfaces (various different HUI/Motu/Korg devices via the CSS GUI and each one deleted without issue.... and remained deleted...
Then I installed a Novation Impulse driver... tried to delete it and it didn't correctly delete.... I also re-installed a Logic Remote and Transport drivers and they all continue to delete as normal...
Again, this only happens with certain drivers and not all... so my suspicions are its more likely driver specific related (maybe permissions related too) than LP related though of course there is a possibility it is both.....
I'll post up screenshots in the following post....

Resolving a TCP connection "slowdown" problem

SuSE 9.3, stock kernel
Intel architecture
Jrockit-R26.4.0-jdk1.5.0_06-linux-ia32
I have a problem that appears to be localized in Jrockit (or
localized in the application, which is localized in Jrockit), where a
persistent and high-volume TCP connection slows down over the course
of about an hour--and eventually, effectively halts.
The TCP traffic is a stream of data, arriving at a near-constant rate
of about 16K bytes per second, with the receiving end (with the JVM
and app) strictly sending TCP ACKs in reply.
Restarting the sending process, or shutting down and restarting the
connection with the JVM / app, both restore the connection to full
speed until, over the course of perhaps an hour (sometimes more,
sometimes less) the same symptoms appear.
The symptoms in network packet traces are that when the connection is
first opened, the sender transmits packets at the full MTU of the
Ethernet segment. Gradually, the number of full-MTU sized packets
are replaced with packets much smaller packets, until most packets
range from 1 to 4 bytes with the occasional 3xx-4xx byte packet and
the odd offlier of a full-MTU packet size.
Supporting symptoms of interest:
1) The TCP window does not shrink
2) The CPU on the JVM/app side tops out at around 20%, even with
mySQL running on the machine
3) The interval between successive ACKs transmitted from the JVM/app
size generally narrows over the course of the connection
4) TCP send queue on the sender becomes saturated (pegged at 90+ K)
5) TCP receive queue on the JVM/app side is almost always 0, and when
it is not zero is bursts up to a low number (<50) and then almost
immediately returns to 0
6) The app does not appear to present any general symptoms of
slowness; the rate of writes to the database does not appear to slow.
The writes are threaded and multiplexed
[4] strongly implies that the slowness is caused by the JVM/app side,
since if the sender app was slowing down for some reason its TCP send
queue would not be saturated.
I can copiously document everything stated, and additionally provide
much additional detail.
Any guidance on how to suss out role Jrockit or the app are playing
in this little drama would be very deeply appreciated.

Asked around and it seems unlikely that this is a JVM issue. We have never heard of this behavior before, and the network layer in the JVM doesn't do anything with MTU iirc with the possible exception of manual changes to socket options. It seems more likely that this is caused by the IP stack, the NIC device driver or something in the network configuration. Try making some changes here and see what happens. For instance:
1) Run client and server on the same machine, communicating through loopback
2) Try another Linux distro (CentOS 4.3, for instance)
3) Try a different NIC and/or a different device driver
In your Java code, check that you are closing all Socket objects properly. Leaving them to be closed by a finalizer can delay closing sockets resulting in a native resource leak. I don't see how that would cause the issue you describe, but you never know...

Proper method to reset tcp connection after timeout error

I have a application that I am building that communicates with a Modbus TCP device. If a communications error occurs I would like to be able the reset the TCP communications. What I have is a control that fires a event when pushed. In this event I have a sequence that first closes the tcp connection and then opens a new connection. My applications starts and runs fine. To test the reset function I removed the ethernet cable from the device and waited of a timeout to occur. I plugged the cable back in and pushed my reset control. Occasionally the reset will occur but most times I will get a time out error at the Open TCP vi. After this, the only way I can establish communications is to exit my application, disable and then enable my network device. Then when I restart my application I have communications with my device.
Any help would be appreciated on how I should be resetting my TCP connection.
Thanks
Terry
Solved!
Go to Solution.

Terry S wrote:
I have attached a example vi (LV10) that shows just the TCP connection and Reset. An error will occur when trying to perform the open tcp in the reset event.
As written your code should be fine. There is nothing inherently wrong with it. However depending on the device you are communicating with you may be trying to reestablish the connection too quickly after you closed the connection. The device may not allow multiple connections to it and may require sometime to clean things up on its end after you close a connection. As an experiment trying waiting a short time between the TCP Close and the TCP Open. If possible you may want to try using Wireshark to see what is happening on the network. It can be useful in diagnosing what is going on.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

WAAS - TCP Connection High-Water Mark

Is there a way to tell the historical statistic for maximum number of TCP connections in a WAE? We are in the middle of a deployment and I am wondering how well we sized our HQ cluster.

Through CM dashboard -> manage devices and go to edge or core device, you will be able to see the connections for each device.
The other option, is to check and see if you are seeing a lot of bypass traffic.
Once WAAS reaches max, traffic will be bypassed until max sessions drops

Device controller - Is it necessary for a lab test?

Hi all,
Newbie here, nice to finally see an RFID with some actual SAP content and real life experiments
Anyway, we are about to start to test the AII with R/3 and we have purchased all the hardware (fixed and mobile readers). I was wondering whether it was to bypass the device controller and "plug" our readers directly into AII? I know that it wouldn't be realistic in a real life environment, but right now we are more interested in just making the thing work without spending too much $$$
Thanks,
Steve

Hello Steve!
> Our current goal is more to test the R/3 -
> AII integration than to do technical tests on the
> RFID side.
You can't integrate AII with R/3 without using a XI between. Except you are going to do some programming in AII.
> A couple of extra questions:
> - Johannes, you mention that SAP offers a JAVA device
> controller as a reference. Any idea where I may find
> that?
You wrote, that you are using Intermec devices. Ask the Intermec support for the device controller for SAP AII. They have one.
> - What is the ball park price for a device
> controller?
A device controller is hardware specific. So, your hardware vendor should provide you with the necessary software. If not, you have to use some generic solution, which is normally much more expensive.
If you consider to program something by our own, take a look at the HTTP and XML capabilities of Microsofts .NET compact framework. It runs on Pocket PC 2002 and higher.
Communicating with AII is the easy part. You just need to be able to send XML messages, formatted using the PML specification publicly available from EPCglobal, and a HTTP library to transport the messages to AII.
Communicating with the RFID devices is the much more difficult part of it. You need to know how the data is organized on your RFID tag (EPC data tag formatting is standardized by EPCglobal), you need a OS specific driver for your reader interface (Intermec IP3 on WinCE/PocketPC) and you need a LAN/WLAN connection to AII.
Once you are able to read your tags, you will face a lot of troubles with reading errors, multiple readings and so on. Your DC software have to handle that.
You will find more on the DC stuff here: http://www.radioactivehq.org/ and here: http://www.i-konect.com/singularity/
Greetings,
Johannes

Is something intercepting my TCP connections?

I have BT Infinite and have been testing my network latency using Ping for ICMP RTT, and NPing to measure TCP SYN/ACK RTT and UDP RTT.
I have found that my TCP connect latency, i.e. time create a TCP connection to a remote host, is always about 10ms, even when the ping is much higher. For example my ICMP ping to the time server 0.uk.pool.ntp.org (192.238.80.20) is about 160ms, but my TCP ping is about 10ms. I get the same result for almost any server on the internet anywhere in the world on any port, the TCP ping varies between 3ms and 12ms.
This implies that something local to my internet connection is intercepting my TCP connections, responding to my TCP connection requests and forwarding on the request to the remote host, e.g. a TCP proxy server, or firewall. The ping and TCP connection time to my broadband router is 1ms or under so its not my equipment. So I assume BT have some device on my connection path.
Has anyone experienced similar issues or knows what is causing this? Is it Parental Control network filters - I thought these worked by blocking DNS requests not by proxying and filtering traffic?

I have BT Infinite and have been testing my network latency using Ping for ICMP RTT, and NPing to measure TCP SYN/ACK RTT and UDP RTT.
I have found that my TCP connect latency, i.e. time create a TCP connection to a remote host, is always about 10ms, even when the ping is much higher. For example my ICMP ping to the time server 0.uk.pool.ntp.org (192.238.80.20) is about 160ms, but my TCP ping is about 10ms. I get the same result for almost any server on the internet anywhere in the world on any port, the TCP ping varies between 3ms and 12ms.
This implies that something local to my internet connection is intercepting my TCP connections, responding to my TCP connection requests and forwarding on the request to the remote host, e.g. a TCP proxy server, or firewall. The ping and TCP connection time to my broadband router is 1ms or under so its not my equipment. So I assume BT have some device on my connection path.
Has anyone experienced similar issues or knows what is causing this? Is it Parental Control network filters - I thought these worked by blocking DNS requests not by proxying and filtering traffic?

NI VBAI TCP Communication With Staubli CS8 Controller

I have a Staubli CS8 controller running the VAL3 programming language. Their documentation is light but I managed to brute force the solution to controlling DIO (Digital Input/Output) commands. I am having trouble brute forcing the SIO (Serial Input/Output) commands. The Staubli appears to only be capable of being the TCP/IP communication Master. I have my laptop's IP address configured in the Staubli controller with the ethernet socket name of "test". With the NI VBAI TCP/IP communication manager set up as slave and the TCP server enabled, the Staubli controller claims it is actively communicating with the NI VBAI socket server, and status is OK. In the VAL3 programming language I believe I have correctly linked the sioLink(siotest,io:test) between the variable name and the actual hardware device port. I try to send serial text strings from the CS8 to the VBAI. But I cannot figure out where to observe the serial communication traffic in VBAI. I have it set up right now to run infinitely and check the TCP port for serial input, but don't see any results. Anyone integrate these two systems yet? I have been using both for quite some time so I'll catch on fast if someone can run me through some quick steps if they have done this before with NI and Staubli. Thanks.

Actually the VBAI side of the communication was easy and straighforward. Plenty of help files and info on the NI support site. The Staubli side was more complex with minimal information supplied in the programming manual, and I was having trouble with that. After experimenting further I was able to transfer data between VBAI and the CS8 controller. If anyone else ever tries this here is what you need to on the Staubli side of the communication:
Set up the ethernet socket on the teach pendant:
Create a new socket and call it VBAI (or anything you really want)
Set the Staubli up as the TCP communication SERVER
Set the termination character for " ; " which is Staubli ASCII character 59 (default is ASCII character 13 which I could not generate in VBAI)
Create the Staubli program (VAL3 language ONLY):
Create a new program in your application
You need to create a serial input output variable (In the data sheet add a new SIO variable, call it sioASCII or whatever you want)
Also create a string variable (In data sheet add a new STRING variable, call it sTEXT or whatever)
Now you must link this variable to the actual hardware socket
Then read the socket and output the value to the teach pendant display screen like this:
UserPage ()
CLS ()
sioLink ( sioASCII , io:VBAI)
sTEXT = sioASCII
putLn ( sTEXT )
Run your VB Inspection on infinite loop first, then run the Staubli program and the inspection data will be displayed on the CS8 teachpendant. Yeah, it always looks to easy after you figure it out the hard way.

Clearing TCP Connections

Hi,
Is there a WAAS command that will allow me to clear a TCP connection thats been hung for 500+ hours? The WAE is running 4.0.13.b23.
Thanks,
Mike

Thanks Zach,
The app (the only app I've had issue with) in question is a home grown product and I'm not quite sure whats causing the WAE to keep connections so long. I've check asymetric routing etc...but traffic is routing correclty. I think it's an app issue but the developers here don't like it when I say that:) My local SE and CCIE worked on this alittle last week in there lab but I had to finally remove the client and server from my WCCP ACL at the central location. Once I did that it removed the hung connections at the remote WAE (it's inline at the site) but when I logged into the 7300 at the central location I noticed they never cleared on that device. It's not building any new connections just hanging onto the old....for instance some have been open for 1000+ hours. I just don't want to force a reboot to get them cleared but it looks like my only option.
Mike

Cannot connect to the device anymore

I have been using the above device (HP Photosmart 5510 e-All-in-One Printer - B111a), for several months, to print, scan and copy. The printer is configured wirelessly and is used by 2 different PCs (a desktop running Windows 8 and a laptop running Windows 7). Today, don't know for what reason, we cannot connect to the device from either of the two machines. I've unsuccessfully tried to re-set the wireless connection twice, including by re-running the set-up program. The printer function itself DOES work, it’s the wireless connection that doesn’t, as written in a diagnostic report I printed after failing to set up the device again using the device’s menu: “Your HP printer is unable to connect to your wireless router ... caused by the settings on the router ... and suggesting to change the wireless router encryption setting to “WPA-AES” or “WPA-AES or TKIP” and run the Wireless Setup Wizard again” . message and the webpage times out. If I try to run the setup from the Photosmart software on the PC, I get a message “The server at 192.168.0.20 is taking too long to respond” and the connection never occurs. ALSO, I've received a couple of errors saying that if I installed the printer by IP address, I might need to update the IP address and to use the Update IP Address item in the Start menu entry for the printer. I don't think I used the IP Address method to install the printer in the first place and, at any rate, I don't know where to find the Start menu for the printer.
Is anybody able to help?
Thanks, Franco

Welcome back to the HP Community @Franco111 !
I hope to lend you a hand with the wireless connection issues you are currently have with your Photosmart 5510 and your network.
I would first suggest power cycling the network devices, in this order:
Turn off the printer and computer and unplug the router for 1 minute (do not press any buttons on the router).
Plug the router back in and wait another minute, next turn on the printer and computer.
Run the Print and Scan Doctor to see if the tool can detect the printer on your network now.
If you are still not connected, try scoping out and trying this guide: HP Photosmart 5510 e-All-in-One Printer Series - Unable to Connect to a Wireless Network When Using ...
When you print out the Wireless Network Test Report, you will see your IP address. Try accessing the Embedded Web Server (printers webpage), from your PC by typing in the IP address in to a web browser.
If you are still getting a message to check your router settings, here is what you are looking to check over:
Network name and password to have no spaces or punctuation.
If using WPA2 security, switch to WPA personal.
Dual broadcast Wireless b/g/n (printer may connect to g).
Turn Mac Filtering Off.
Firewall settings need to be at their default settings, or set to a lower security.
Multicasting "on".
Following ports need to be un-blocked:
Incoming (UDP) ports : 137, 138, 161, 427
Outgoing (TCP) ports : 137, 139, 427, 9100, 9220, 9500
Let me know the results so far and we will go from there!
R a i n b o w 7000I work on behalf of HP
Click the “Kudos Thumbs Up" at the bottom of this post to say
“Thanks” for helping!
Click “Accept as Solution” if you feel my post solved your issue, it will help others find the solution!

Flush TCP connection

Hello,
I am trying to capture data from the TCP connection, however, there are instances where I may only have say 5kbytes of data and when I have a lot more. If I take the 'bytes to read' beyond 6000, the program hangs.
Is there some way to flush the TCP connection so that when I send the next set of commands over the TCP connection, I can just capture the current set of data instead of the whole bunch of data that is sent from my machine?
To give you a better understanding of my overall program, I am testing out a device over TCP. Only if I reset the device and send a read command, I get some of the data from my attached program. Because I am just limited to setting the 'bytes to read' to 6000, I cannot capture all the data. Is there another way to caputure all the data after the device reset?
Thanks,
hiNi.
Attachments:
TCPIP test for email.vi ‏36 KB

TCP has several mode inputs that you should look at and understand. The online description is pretty conclusive about them.
Basically your read function does not hang but waits for the specified timeout which by default is set to 25000 ms. There is nobody that forbids you to specify a different timeout. For instance TCP Read with a timeout of 0 or 1 will return instantaneously no matter how much data is available. Together with the mode Immediate, this will flush whatever data is present if you use a big enough number of bytes to read. You can verify that the number of bytes returned is smaller than what you have specified to read and if that is not the case issue another read with the same conditions until you receive a buffer that is smaller than you specified to read.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

WAE-512-1G Optimized TCP Connections

Hi all,
Regarding the Sizing Capabilities of a WAE-512-1G Appliance, what is the meaning of the "Optimized TCP Connections" ?
Is this parameter related only from the initiated point ? or from both directions?
I'm asking this because, after instaling in inline configuration, a point-to-point circuit only, (2 WAE's + 1 CM), in the Branch WAE we had a Minor Alarm saying that we have reached the TFO Limitation, and on the ohter end, we haven't that alarm.
Most of the traffic(connections), should be from the Branch to the Central Site.
So, the main question is, if this parameter is related to from where the connection is initiated.
Best Regards,
Bruno PetrÃ³nio

The branch Cisco WAE applies a new TCP option (0x21) to the packet if the application is identified for optimization by an application classifier. The branch Cisco WAE adds its device ID and application policy support to the new TCP option field. This option is examined and understood by other Cisco WAEs in the path as the ID and policy fields of the initial Cisco WAE device. The initial ID and policy fields are not altered by another Cisco WAE. The packet is forwarded to the branch router and then to the WAN.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/App_Networking/citrixdg_final.html

TCP Connection to a Device Controller

Similar Messages

Maybe you are looking for