"keep alive"-signals from TCP-connections

Hi,

is there a way to filter out the keep alive-signals from a TCP-connection or whatever those symbols are (IIRC it’s p and a square over and over again). They appear when having a Java applet connected to a vvvv TCP-listener. Using the console and manually entering strings doesn’t produce those signals. Also, I guess if you send too many strings at once, most of them get lost. I couldn’t really reproduce this behaviour because it seemed to happen randomly.

Regards
Dan

hei dan,

They appear when having a Java applet connected to a vvvv TCP-listener.
if there is something coming via TCP this is application specific. to filter it out you’ll have to find out what exactly your java-applet is sending. if you know it you could compare the incoming stream to the string you want to filter and only let it through if it is not that string. use = (String) and S+H (String) for that.

Also, I guess if you send too many strings at once, most of them get lost.
no, why should this be?

if there is something coming via TCP this is application specific.

Ok, I thought it was something like that. So I guess I have to find out, what Java in sending there. I already tried to switch the keep alive off, but it seems not to be possible with the normal Java libraries. Do you know if using UDP could solve the issue? I have no possibility to find it out right now. But since UDP is stateless, there should be no such thing as keep alive-signals (hopefully).

So I guess I have to find out, what Java in sending there.
i’d say it is not java, but the application which is obviously sending stuff. if you have the sources of that application you should be able to find out what is being sent periodically, if not you’ll have to ask the makers of the application or check its docs.

Do you know if using UDP could solve the issue?
as i believe this is an application-specific thing i’d say neither java, tcp, udp or any other buzz may be of any help as long as you don’t know what is being sent there.

you could of course also just record (queue) the output of the TCP (Server) for some time and see if you can make any sense out of it.