Problem 176 interactive problem Sending correct answer but always end up losing game

Hi everyone,

I've been brushing up on my c++ and thought it would be interesting to try the interactive problems.

At any rate, I started working on the first problem, "Say 100" and eventually cooked something up using a curl library. The problem is that while I seem to get the "secret" from the server, it never accepts my answer as correct, as it always seems to give me the "end: game is lost".

I've been racking my brains trying to figure out what's going on here, trying different things out, reading curl documentation more carefully...

the format of the postfields is exactly what you would expect: for the first request: token=thisIsTheTokenBlahBlahBl and once i get response with secret(let's say.. 60), I do the calculation and send token=thisIsTheTokenBlahBlahBl&answer=40

My initial gut feeling was that perhaps I was sending the messages wrong, but the fact that the server accepts my first token and responds to me with the "secret" somewhat discredits that.(Plus some trial and error attempts at changing the format of the messages...)

In a nutshell whenever i send a message i basically do this:

/* some previous stuff to setup curl handle properly */

// let's say I am sending the 2nd message with the answer
string message = "token=thisIsTheTokenBlahBlahBl&answer=40";

curl_easy_setopt(curl, CURLOPT_POSTFIELDS, message.c_str());
int res = curl_easy_perform(curl);

I can provide the full source if someone who has already solved it asks for it. I'm fairly sure it is almost a complete solution, but was hesitant to upload it here since I didn't want to ruin the fun for those who haven't tried it.

Thanks in advance for any help.

Thanks for your response Quandray,

I turned on the curl verbose mode, and I didn't catch anything unusual, the content-lengths seem to be fine as well. The 1st message is 31 bytes, and the 2nd, having 10 more characters from the additional "&answer=49", shows up just fine at a content-length of 41 bytes. What am I missing here?

This is the output of a test run (note, lines beginning with 2 tildes ~~ are my own printouts of messages I have received or are about to send)

~~SENDING: token=Y3FR2Dy0/1qGwi8SCFwZ3jQw
* Hostname was NOT found in DNS cache
*   Trying 216.34.181.96...
* Connected to codeabbey.sourceforge.net (216.34.181.96) port 80 (#0)
> POST /say-100.php HTTP/1.1
Host: codeabbey.sourceforge.net
Accept: */*
Content-Length: 31
Content-Type: application/x-www-form-urlencoded

* upload completely sent off: 31 out of 31 bytes
< HTTP/1.1 200 OK
* Server Apache/2.2.15 (CentOS) is not blacklisted
< Server: Apache/2.2.15 (CentOS)
< Vary: Host
< Cache-Control: max-age=172800
< Expires: Mon, 10 Aug 2015 08:08:01 GMT
< Content-Type: text/plain
< Content-Length: 12
< Date: Sat, 08 Aug 2015 08:08:01 GMT
< X-Varnish: 139255662
< Age: 0
< Via: 1.1 varnish
< Connection: keep-alive
< 
~~RECEIVED: secret: 51

* Connection #0 to host codeabbey.sourceforge.net left intact
~~SENDING: token=Y3FR2Dy0/1qGwi8SCFwZ3jQw&answer=49
* Found bundle for host codeabbey.sourceforge.net: 0x7fbce960a2f0
* Re-using existing connection! (#0) with host codeabbey.sourceforge.net
* Connected to codeabbey.sourceforge.net (216.34.181.96) port 80 (#0)
> POST /say-100.php HTTP/1.1
Host: codeabbey.sourceforge.net
Accept: */*
Content-Length: 41
Content-Type: application/x-www-form-urlencoded

* upload completely sent off: 41 out of 41 bytes
< HTTP/1.1 200 OK
* Server Apache/2.2.15 (CentOS) is not blacklisted
< Server: Apache/2.2.15 (CentOS)
< Vary: Host
< Cache-Control: max-age=172800
< Expires: Mon, 10 Aug 2015 08:08:02 GMT
< Content-Type: text/plain
< Content-Length: 19
< Date: Sat, 08 Aug 2015 08:08:02 GMT
< X-Varnish: 139255679
< Age: 0
< Via: 1.1 varnish
< Connection: keep-alive
< 
~~RECEIVED: end: game is lost

* Connection #0 to host codeabbey.sourceforge.net left intact
Press ENTER to end...

Ah I got it! Thanks Quandray!

I had a feeling that my issues were going to come down to some careless mistake!

The curl's verbose mode got me thinking about the content-lengths some more. I noticed that the request's content-length counted an extra byte, which I quickly attributed it to the newline characters I had been appending to my outgoing messages. I don't know why I assumed that the messages had to be terminated with a newline character, but as soon as I became aware of my baseless assumption, I knew that it was the source of all my issues.

Got rid of those newlines, and voila, success!