Klaus_EAN
13th April 2007, 10:27
Hello to all,
I have registered here, because I have serious problems with tcpsocket-connections. Maybe someone knows how to solve my problems.
And yes, I have searched in the database here before posting this.
Problem description:
Transfering data from a client (in the same subnet) to the server causes a port-switching between the
first syn-flag and the later communication. This is not seen, if client runs on the same box as the server.
At least data will be "lost" (resp. not "catched") on the server side, if client is not local and data to be transfered is bigger (appr. 65KB).
Situation:
Operating system is Ubuntu 6.xx, compilation with qmake/make for Qt4-stuff
A Qt-client makes a connection to a server, which is implemented in C/C++ (can't use Qt!!)
The client is fully designed/coded with Qt4 designer and QTcpSocket-stuff.
The instantiation of the socket-object is done dynamically with the "new" operator (client).
The steps on client side to communicate:
tcpSocket = new QTcpSocket(this);
tcpSocket->connectToHost(thehostip, spinBox_port->value());
tcpSocket->waitForConnected(1000))
qint64 byteswritten = tcpSocket->write(thedata);
tcpSocket->waitForBytesWritten();
After this, an "additionally" check on client was done, that the whole amount of the file, which has been read to send, was really sent.
I tried this to achive the goal:
On server side "tcpdump" watches the networktraffic (filter all syn- and fin-flags with 'tcp[13] & 3 !=0').
If client is on the s a m e box you can see the following sequence:
Syn, Syn, Fin, Fin on the same port (negotiated after the first contact, initial port is 5555, then e.g. 37690).
If client is on a different machine but in the same subnet you can see the following sequence:
Syn, Syn, port switching +1 Syn (new port),Syn (new port), Fin (new port), Fin (new port)
Sometimes the second Fin is NOT seen, if file is big (tested with appr. 64200 bytes).
Using the "swiss knife" netcat on client side (same subnet) with the big file, there is NO portswitching (nc 192.168.100.71 5555 < big_file).
On server side the following code snippets are used to establish a "listen" and "accept" (BSD-sockets!)
(/* C/C++ */)
TCPSocket * theSock = new TCPSocket ();
int ret = theSock->Bind(host, port); //bind and listen combined!
TCPSocket * theNewSocket = theSock->Accept(); // this is done in a loop forever
int NumberBytesRead = theNewSocket->Read(theBuffer, BUFFER_SIZE);
ioctl(theNewSocket->sock, FIONREAD, &rlen); //watching, if there is (fragmented)data on the socket not read yet
while (rlen > 0)
{
int NumberBytesRead = theNewSocket->Read(theBuffer, rlen);
.... Handle_theBuffer...
ioctl(theNewSocket->sock, FIONREAD, &rlen);//update register, maybe more to read?
}
Thanks for reading my post till here.
I would be happy to give more information, if needed.
Thanks again, hoping for an answer.
With best regards
Klaus
I have registered here, because I have serious problems with tcpsocket-connections. Maybe someone knows how to solve my problems.
And yes, I have searched in the database here before posting this.
Problem description:
Transfering data from a client (in the same subnet) to the server causes a port-switching between the
first syn-flag and the later communication. This is not seen, if client runs on the same box as the server.
At least data will be "lost" (resp. not "catched") on the server side, if client is not local and data to be transfered is bigger (appr. 65KB).
Situation:
Operating system is Ubuntu 6.xx, compilation with qmake/make for Qt4-stuff
A Qt-client makes a connection to a server, which is implemented in C/C++ (can't use Qt!!)
The client is fully designed/coded with Qt4 designer and QTcpSocket-stuff.
The instantiation of the socket-object is done dynamically with the "new" operator (client).
The steps on client side to communicate:
tcpSocket = new QTcpSocket(this);
tcpSocket->connectToHost(thehostip, spinBox_port->value());
tcpSocket->waitForConnected(1000))
qint64 byteswritten = tcpSocket->write(thedata);
tcpSocket->waitForBytesWritten();
After this, an "additionally" check on client was done, that the whole amount of the file, which has been read to send, was really sent.
I tried this to achive the goal:
On server side "tcpdump" watches the networktraffic (filter all syn- and fin-flags with 'tcp[13] & 3 !=0').
If client is on the s a m e box you can see the following sequence:
Syn, Syn, Fin, Fin on the same port (negotiated after the first contact, initial port is 5555, then e.g. 37690).
If client is on a different machine but in the same subnet you can see the following sequence:
Syn, Syn, port switching +1 Syn (new port),Syn (new port), Fin (new port), Fin (new port)
Sometimes the second Fin is NOT seen, if file is big (tested with appr. 64200 bytes).
Using the "swiss knife" netcat on client side (same subnet) with the big file, there is NO portswitching (nc 192.168.100.71 5555 < big_file).
On server side the following code snippets are used to establish a "listen" and "accept" (BSD-sockets!)
(/* C/C++ */)
TCPSocket * theSock = new TCPSocket ();
int ret = theSock->Bind(host, port); //bind and listen combined!
TCPSocket * theNewSocket = theSock->Accept(); // this is done in a loop forever
int NumberBytesRead = theNewSocket->Read(theBuffer, BUFFER_SIZE);
ioctl(theNewSocket->sock, FIONREAD, &rlen); //watching, if there is (fragmented)data on the socket not read yet
while (rlen > 0)
{
int NumberBytesRead = theNewSocket->Read(theBuffer, rlen);
.... Handle_theBuffer...
ioctl(theNewSocket->sock, FIONREAD, &rlen);//update register, maybe more to read?
}
Thanks for reading my post till here.
I would be happy to give more information, if needed.
Thanks again, hoping for an answer.
With best regards
Klaus