Strange QTcpSocket behavior (debugged with Ethereal)

[Thoosle]

Hi Wysota,

The server I use closes down for the weekend until later tomorrow, maybe I'll write/test thi with something minimal then but in testing this yesterday I've commented out my code down to either of the following two cases.......it's as minimal as it gets....

in the parent object constructor...... QTcpSocket *pSocket = new QTcpSocket(this);

then in a parent object method the first case.....

pSocket->connectToHost( host, port);

if(!pSocket->waitForConnected(1000))
{
return false;
}

or the second case with just connectToHost() alone.....

pSocket->connectToHost(host, port)

comparing these two cases and looking at the initial tcp/ip 3 packet exchange witih Wireshark(ethereal) the latter works properly. The former results in the client first sending the initial packet with the SYN flag set and a return port of say 30000. But, this is follwed by it sending another packet with SYN but the return port is incremented by 1. It's as if the first attempt failed and so it attempts again. The third packet is the server sending SYN and ACK to the first request. The client then sends RST to close that connection!! All as if "waitForConnect" is somehow adversely affecting things andI have no idea why.

[wysota]

Can't you use... I don't know... www.google.com:80 as the server?

The reason I ask about a compilable example is that you can (1) verify your own code and make sure you can reproduce the problem without any other code influencing it and (2) we can work on the same code and try to reproduce the problem ourselves. In many cases just implementing the minimal example is enough as the author discovers the problem himself (as the code is minimal and doesn't try to do anything else - see reason1).

[Thoosle]

wysota,

Yes, of course what was I thinking??? I wrote the following:

#include <stdio.h>
#include <stdlib.h>
#include <QtNetwork>

int main(int argc, char *argv[])
{
QTcpSocket *pSocket = new QTcpSocket;

pSocket->connectToHost("www.google.com", 80);

if(pSocket->waitForConnected(1000))
{
printf("\nconnected!\n");
}

return EXIT_SUCCESS;
}

this runs and exits normally and shows "connected" printed out. And the captured packet exchange looks normal but I get the following two run time messages:

QObject::connect:Cannot connect (null)::aboutToQuit() to QHostInfoAgent::cleanup()
QObject::connect: Cannot connect (null)::destroyed(QObject *) to QHostInfoAgent::cleanup()

but if you comment out:

if(pSocket->waitForConnected(1000))
{
printf("\nconnected!\n");
}

then the code runs same as above but with no QObject... messages

[wysota]

I think there is nothing to worry about here. Try creating a QApplication object at the beginning of main. The warnings will probably disappear.

So the bottom line is the transmission is fine? If so, then compare this code to your original application and try to spot differences.

[Thoosle]

wysota,

Yes, the packet exchange seems solid now. Question: could it possibly be a server related thing like a timing issue of some sort with the host? The reason I ask is because in my app when I say I've commented everything down to a few lines of code, I'm not kidding, I did just that. I don't see anything else that could be involved, but, of course what I'm not seeing is probably where the answer is The only thing I haven't done is to try that code, with a different server. Which is next on my list...... I'll report if I find anything useful........thanks!!

[Thoosle]

wysota,

I just tried the entire offending project code, execpt I edited the host and port values in connectToHost() to point to google.com port 80 and connected with perfect handshake 5 times in a row. There is no way the server I've been connecting to would do that. No conclusions here just fyi....... Tomorrow I'm going to try the simplified code with the server in question when it comes back on line and see what that does.....

[wysota]

Does the "presumed faulty" server run IIS, by any chance?

[Thoosle]

I have no idea......

[wysota]

Forget it, it doesn't matter. I somehow assumed you were using the HTTP port which is surely a false assumption...

What kind of service (application) do you connect to? Did you write it yourself or is it some well known daemon?

[Thoosle]

Hello Witold,

First, FYI I just tried the minimal code with the server in question and it had a weird initial handshake 5 out of 6 times.....apparently it's not Qt at all but the server.......

I'll try to answer your question: I have a small lan here and it has a windows xp machine and Linux machine. I trade index futures on the XP machine with a java app(provided by the brokerage) that connects to the brokerage server in New York and I use this app to place orders. Also on the XP machine is a charting application(from a different company) to chart the futures data and I pay an annual fee for this charting app. This charting app connects(via local loop) using tcp/ip to the java trading app(all on the xp machine) to get historical and live streaming data.

The java app for trading is the interface to my brokerage and is the "server" that I'm connecting to. They(the brokerage) provide an API so I can write my own trading and charting apps if I so choose. The java trading app is the interface to the brokerage that takes care of my logging in and trading, etc and any app I might write will have to communicate with and through this trading app. And since this trading client app is a Java app I can also run it on my linux machine and it works great there.(haven't checked for this prob. on linux).

What I'm working on is a Linux/Qt charting app to replace the one I'm paying for. This would allow me to move my trading/charting to my Linux machine...one of the last things I do on that machine and part of my goal to get away from windows(and save myself a little money as well). So, in the meantime as I work on my app, the server that I'm connecting to is, as I've said, just the xp machine 3 feet to my right that's running the java trading client(server).

[Thoosle]

I think I have a better understanding of what the problem is although I can't say why it is.....only the server knows for sure.....

In looking at wireshark and referring to the initial tcp/ip handshake, when the initial SYN packet is sent I see now that it is taking approx 1 msec for the server to respond with SYN and ACK.. But, before the server responds(about 300usec after first attempt) the client has apparently concluded that the connection didn't work and so it increments it's listening port number and sends another SYN packet to again try to connect. So, by the time the server responds(1msec after initial attemp) the client is no longer listening on the original listening port it first sent. And after the server tries to respond to the first connection attempt the client sends RST to cancel that first attempt, since it's no longer listening there!! Shortly after that the server catches up and replies with SYN/ACK to the second attempt. From that point communication proceeds normally.

I think this is exactly what was happening to the original posters on this thread . For what ever reason, the server I'm connecting with is not responding to the first connection attempt fast enough!! I worked around this in my code by putting connectToHost in it's own method that simply invokes it and returns. The socket connected or error signals invoke either a connected method or a method to deal with the failed connection attempt.

The question at this point is.....is the server not responding fast enough or is the connection attempt unreasonable in it's expectations regarding timing? Anyone have thoughts on this? Is the server simply slow or do I need to configure something relative to the socket or Linux or whatever?

[wysota]

But, before the server responds(about 300usec after first attempt) the client has apparently concluded that the connection didn't work and so it increments it's listening port number and sends another SYN packet to again try to connect.

TCP doesn't work that way. Timeouts are much longer and SYN should be repeated on the same port. Using a different port suggests the previous try was abandoned..

And after the server tries to respond to the first connection attempt the client sends RST to cancel that first attempt, since it's no longer listening there!!

This is a regular behaviour. You could try to use iptables (or simmilar) to stop the client machine from sending RST (-j DROP instead of -j REJECT) and see what happens then.

Shortly after that the server catches up and replies with SYN/ACK to the second attempt. From that point communication proceeds normally.

So why doesn't it happen with the second attempt?

I think this is exactly what was happening to the original posters on this thread . For what ever reason, the server I'm connecting with is not responding to the first connection attempt fast enough!!

There is nothing like "fast enough" with TCP. The initial TCP timeout can often be changed by tweaking system settings, but it's surely bigger than 0.1s. Otherwise you could never connect to lagging or distant servers (connections through a satellite link would also not be possible).

The question at this point is.....is the server not responding fast enough or is the connection attempt unreasonable in it's expectations regarding timing? Anyone have thoughts on this? Is the server simply slow or do I need to configure something relative to the socket or Linux or whatever?

I suggest you try with different servers. If you were connecting to IIS, it has a well known "feature" of cheating the statistics and you might be experiencing that. But since you're connecting to some java software, it's either the software problem or the operating system. Does the same happen (on the same target box) when using Qt servers from networking examples?