wrong syntax or QTcpSocket problem?

[vito49]

Hello, the first QT program i'm writing is a NNTP program to post binaries.
Up to now I managed to connect with the server and to read its response to several commands I give (like 'POST' and 'HELP'). So far so good.
Of course I first try to send a small message with only text in the body, and if this works I can focus on sending binaries.

But I have a problem I don't understand ... when I try to send that message I need to do it as in this code:

QString t;
	QString CRLF("\n");
	t.clear();
	t.append("From: " + userName +  + CRLF);
	t.append("Newsgroups: " + (comboBox->currentText()) + CRLF);
	 /// and so on with a few other commands more
 
       tcpSocket->write(t.toAscii().data());  //this writes the data to the socket

QString t;
	QString CRLF("\n");
	t.clear();
	t.append("From: " + userName +  + CRLF);
	t.append("Newsgroups: " + (comboBox->currentText()) + CRLF);
	 /// and so on with a few other commands more

       tcpSocket->write(t.toAscii().data());  //this writes the data to the socket

To copy to clipboard, switch view to plain text mode 

With this code the server returns a '500', meaning it doesn't understand the commands.

Now I found out that if I remove the 'CRLF' the newsserver doesn't complain but of course nothing is posted. And I know from an existing program the cr/lf must be there. Here's a snippet from that c-program I sometimes use, called 'newspost' (but this text based program is no longer maintained for Linux).

buff = buff_add(buff, "From: %s\r\n", data->from->data);
	buff = buff_add(buff, "Newsgroups: %s\r\n", data->newsgroup->data);
	buff = buff_add(buff, "Subject: %s\r\n", subject);
	buff = buff_add(buff, "User-Agent: %s\r\n", USER_AGENT);
  // and so on ...

buff = buff_add(buff, "From: %s\r\n", data->from->data);
	buff = buff_add(buff, "Newsgroups: %s\r\n", data->newsgroup->data);
	buff = buff_add(buff, "Subject: %s\r\n", subject);
	buff = buff_add(buff, "User-Agent: %s\r\n", USER_AGENT);
  // and so on ...

To copy to clipboard, switch view to plain text mode 

For the CRLF I tried "\r\n" too ... with the same result.
Here's the routine to read the server, it works without problems.

void myQtApp::readHost()
{
	QMessageBox msgWarn;
	QString s;
	QString t;
	s.clear();
	t.clear();
	s=tcpSocket->readLine();
 
	switch(s.left(3).toInt()){
	case 100:
	t.append("request for help granted");
	break;
	case 200:
	t.append("server ready to receive");
	break;
	case 211:
	t.append("newsgroup valid and selected");
	break;
	case 221:
	t.append("no data follows");
	break;
	case 340:
	postFiles();
	break;
	case 500:
	t.append("wrong command");
	break;
	case 501:
	t.append("wrong syntax after command");
	break;
	default:
	t.append(s.left(3));
        // temporarily messageBox for control
	msgWarn.warning(this, "server says", s.toAscii().data(), QMessageBox::Ok);
	break;
	}
 
      label_status->setText(t);
}

void myQtApp::readHost()
{
	QMessageBox msgWarn;
	QString s;
	QString t;
	s.clear();
	t.clear();
	s=tcpSocket->readLine();
	
	switch(s.left(3).toInt()){
	case 100:
	t.append("request for help granted");
	break;
	case 200:
	t.append("server ready to receive");
	break;
	case 211:
	t.append("newsgroup valid and selected");
	break;
	case 221:
	t.append("no data follows");
	break;
	case 340:
	postFiles();
	break;
	case 500:
	t.append("wrong command");
	break;
	case 501:
	t.append("wrong syntax after command");
	break;
	default:
	t.append(s.left(3));
        // temporarily messageBox for control
	msgWarn.warning(this, "server says", s.toAscii().data(), QMessageBox::Ok);
	break;
	}

      label_status->setText(t);
}

To copy to clipboard, switch view to plain text mode 

It puzzles me that the server doesn't accept a carriage return ... well, to be honest I do believe it's my code that is in error, not the server. Or is it something with the tcpSocket?
I'm stuck

All info welcome. Thanks in advance for your reply.

[mcosta]

Are you sure you're received bytes you need to readLine()?

Where do you set the code you check?

s.left(3).toInt()

s.left(3).toInt()

To copy to clipboard, switch view to plain text mode 

[vito49]

Are you sure you're received bytes you need to readLine()?

Where do you set the code you check?

s.left(3).toInt()

s.left(3).toInt()

To copy to clipboard, switch view to plain text mode 

Thanks for your reply.
But I'm not sure I understand what you mean ...
To read what the server says I use this signal/slot:

connect(tcpSocket, SIGNAL(readyRead()),this,SLOT(readHost()));

connect(tcpSocket, SIGNAL(readyRead()),this,SLOT(readHost()));

To copy to clipboard, switch view to plain text mode 

Every time the server sends a message the readHost() function is called. Here's a piece of code:

switch(s.left(3).toInt()){
	case 100:
	t.append("request for help granted");
	break;
	case 200:
	t.append("server ready to receive");
	break;

switch(s.left(3).toInt()){
	case 100:
	t.append("request for help granted");
	break;
	case 200:
	t.append("server ready to receive");
	break;

To copy to clipboard, switch view to plain text mode 

I only need the first 3 characters to determine the command it sends, so I strip everything from the message except the first 3 characters.

When I send "From: Vito" nothing happens, that seems normal to me because the string is not terminated by a "\n", but when I add a cr/lf the server responds with a '500' meaning it doesn't understand the message sent.

Maybe I don't use the right commands, that's possible, I got them from an older c-program and that worked fine a while ago on the same newsserver.

[vito49]

Are you sure you're received bytes you need to readLine()?

Where do you set the code you check?

s.left(3).toInt()

s.left(3).toInt()

To copy to clipboard, switch view to plain text mode 

OK, there seems to be no problem with the socket but a misunderstanding of commands for the server. When I send "post\n" the newsserver doest complain, it sends a '340' followed by a suggested ID to use for my post. I now derived all commands from the server with 'help\n" command and they are ALL different from the ones I had. Strange but true.

I have to dig into these new commands now