Endless loop of parsing empty sentences when frog server connection is closed

[jsteggink]

Endless loop of parsing empty sentences when frog server connection is closed

[proycon]

Hmm.. strange, I've never seen this... I can't seem to reproduce this yet with frog 0.13.5 and a simpel telnet connection. So when the client disconnects it enters the continuous loop? What client are you using? Could it be a client-side issue?

[jsteggink]

Try to connect using Telnet on Windows, give some random input and then quit Telnet using ^].

[proycon]

That's what I did with telnet on linux. I don't have any Windows machine to test though. I wonder if the windows telnet client emits an extra \r prior to \n that triggers the bug, or does the problem also reproduce if you use the telnet inside the LaMachine VM?

[jsteggink]

Using telnet on Linux gives me no problems. However, I have written a Java client which has the same problem, no "\r" there. I haven't really looked into the loop, but I guess it doesn't see the connection is lost?

[kosloot]

Well, detecting that 'the other side' is misbehaving in a TCP connection is quite hard.
Frog DOES honor both \r and \n line endings (and mix-ups)
A good client should close the connection/socket when done. Don't know about your Java client?
If not, then TCP timeouts should occur, but that can take a LONG time:
The default value on Linux is 7200 seconds! So after 2 hours and then 9 retries, the connection should be dropped.
I tried playing with TCP_KEEPALIVE, but as I don't have a misbehaving client, I cannot test it.

[kosloot]

closed due to inactivity on the isssue

[davesmits]

I have the same problem. I am trying to communicate with a C# program with frog. As long I dont close the TCP connection with frog I am able to get things working. When the tcp connection closes (unit test fininshs) seems frog gets into an endless loop

    [TestClass]
    public class FrogClientTest
    {
        [TestMethod]
        public void Test()
        {
            IPHostEntry ipHostInfo = Dns.GetHostEntry("localhost");
            IPAddress ipAddress = ipHostInfo.AddressList[0];
            IPEndPoint remoteEP = new IPEndPoint(ipAddress, 1234);

            // Create a TCP/IP socket.  
            Socket client = new Socket(ipAddress.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
            client.Connect(remoteEP);

            string eot = "Dit is een test text" + "\nEOT\n";
            byte[] byteDataNewLine = Encoding.UTF8.GetBytes(eot);

            client.Send(byteDataNewLine);

            var buffer = new byte[4096];
            int read = 0;
            StringBuilder result = new StringBuilder();
            do
            {
                read = client.Receive(buffer);

                string receivedText = Encoding.UTF8.GetString(buffer, 0, read);
                result.Append(receivedText);

            } while (read == buffer.Length);

            var response = result.ToString();
            Assert.IsNotNull(response);
            Assert.IsFalse(string.IsNullOrEmpty(response));
        }
    }

[kosloot]

Well, we don't have or do Windows nor C# here, but, looking at your code, I wonder:

What if you explicitly close and/or delete your client?
You do a 'new Socket()' and then Connect() to it.
I assume you can Close() it too?

And maybe C# does garbage collection, but still, a 'delete client' might be worth testing.

[davesmits]

yes I can do a Close() but the behavior stays the same. If I dont call the explicit closem the close happens because the process terminates

[kosloot]

Well, this is difficult to fix, as this seems a Windows only problem.
Explicitly calling client.Delete() didn't help too?
One last resort might be calling client.Shutdown() before close() as MS advises.

[proycon]

Did you also try with \r\n instead of \n? Does that make a difference? (just a wild guess)

[davesmits]

I tried both suggestions, but unfortunately no luck

[kosloot]

Ok, I committed 2 small fixes. One in ticcutils, and one in frog.
I hope this will help.

You need the master versions from git, or lamachine-dev to test this.

[davesmits]

cool thanks. I will check it out. I need to setup a development environment as we been using the dockers till now

[davesmits]

Is this fix already in one of the dockers included?

[proycon]

As it's not formally released yet it's not in the latest LaMachine docker image on Docker Hub yet. However, you can always simply do a LaMachine docker build of the latest development releases if you want (we don't push those to docker hub), just follow the instructions in the LaMachine bootstrap procedure, see https://proycon.github.io/LaMachine. (but be aware that development releases are by definition experimental and might break)

[kosloot]

assume this is solved now