Good day!
I am having a wierd problem: QNAM sends my SECOND request twice. I am not sure how to reproduce the problem (what are actual prerequisites), but I have the code that will demonstrate it 100% of the time. I can also provide screenshot of HTTP sniffer catching those requests. You can see that the request I send at code line 42 effectively gets duped, but the one before and one after (not shown) are sent fine (once)...
My problem is similar to the one shown in this question.
However...
Main differences between that question and mine are:
I am using QNAM in an asynchronous manner with the help of Qt's Signals and slots
I am sending post requests instead of get.
What could be the problem? Is there any way to make it work as it's supposed to?
Thanks in advance! If you need additional info just ask :)
This can happen if the server doesn't return any content in the response. If you control the server, you can add a workaround to return some dummy content.
I just had this issue and after sending down one character in the response, I no longer see the request sent twice. This was with a BlackBerry 10 (QT) hitting an iOS device running Mongoose as the embedded server.
Related
I have some application-level security measures. I'd like to just kill the client connection if we suspect that the current request is suspicious rather than returning a proper response. To produce an ambiguous response to the client that seeks to avoid an outright acknowledgement that they found a webserver. What about being able to call a function right when the incoming connection is accepted and the header bytes are first read? I've tried to just close the request stream from a before_request function or close the response stream in a after_request function, but the former has no effect and the latter will just close the socket after already having written the status and headers.
I did a heavy number of searches into both the lifecycles of Flask and Werkzeug, but didn't turn up anything. It seems like no one has ever asked the connection-abort question before.
It seems like I should be able to catch where the start_response callback is called by Flask and either write my own or intercept it and return my own no-op write function so that the client connection is effectively never acted on, but this requires more research. I couldn't seem to find anywhere in Flask or Werkzeug that actually calls start_response or anything that might refer to this by an alternate name before I ran out of time to look.
Reference: https://github.com/pallets/werkzeug/blob/c7ae2fea4fb229ffd71187c2b665874c91b96277/src/werkzeug/serving.py#L250
I'm new to c++ and I started to code my server with boost. I follow a lot of example on the web and on the official doc. But i found nothing (maybe I don't ask the good question) about this-> communicate with a specific client. By this I mean that->
old question:
Server launch and wait for connection-> client(1) connect through
TCP-> server accept client and start async_read
Let's say 3 clients also connect->
How I'll tell to my server too write too client(2) or (3) but not
both?
I express myself badly
New question:
My server work fine, when client send data to server (custom client in Unreal engine 4) he can read it then write back to my client with no problem. I search a way to speak to the client I want without needed him to send data. Example:
client 1 write to server-> the data send to server launch the next action-> write to a specific client.
More specific example:
Client 1 want to send request to client 10, so client 1 write to the server the action «action, id client» (request, 10) then the server know that he need to talk to the client 10 and send request.
My problem is not on the client side, but on the server side.
I'm sure it's pretty easy and I just don't understand some basic stuff, if someone could provide me a direction, an example or simply an explanation it would be appreciated. Thanks for future answer.
EDIT:
If somebody have hard time like me (I know it's easy but we never know :p, maybe it could help someone) here the answer.
I include this inside the file where I use to connect, write, send, etc.
std::map<int, tcp::socket> playerRemote;
I set it->
playerRemote.insert(std::pair<int, tcp::socket>(id, std::move(socket_)));
use the socket->
boost::asio::async_read(playerRemote.at(id_to_use)
Question resolve! thanks for help!
Every time that your server program did an accept it got a new socket with a new client on the other end of it.
The usual practice is to have some kind of object which you create and initialize with this new socket. And then you put that object into some kind of structure. Like a set, a map, a vector, a list, anything really.
When you want a particular client then search that data structure for it. If you used a map or a unordered_map then you can get it quickly by whatever key you used.
Now you have your client object you can call a method on it. Like your own version of "send" which can add it to a per-client buffer. Since message sending is asynchronous in Boost ASIO (it's right there in the name) you know you may not be able to send it right away.
The Boost ASIO chat example application is good about this.
Look at the link that The Quantum Physicist put in comments. Especially this one: http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/example/cpp11/chat/chat_server.cpp
I am creating a network client application that sends requests to a server using a QTcpSocket and expects responses in return. No higher protocol involved (HTTP, etc.), they just exchange somewhat simple custom strings.
In order to test, I have created a TCP server in Python that listens on a socket and logs the strings it receives and those it sends back.
I can send the first request OK and get the expected response. However, when I send the second request, it does not seem to get written to the network.
I have attached debug slots to the QTcpSocket's notification signals, such as bytesWritten(...), connected(), error(), stateChanged(...), etc. and I see the connection being established, the first request sent, the first response processed, the number of bytes written - it all adds up...
Only the second request never seems to get sent :-(
After attempting to send it, the socket sends an error(RemoteHostClosedError) signal followed by ClosingState and UnconnectedState state change signals.
Before I go any deeper into this, a couple of (probably really basic) questions:
do I need to "clear" the underlying socket in any way after reading ?
is it possible / probable that not reading all the data the server has sent me prevents me from writing ?
why does the server close the connection ? Does it always do that so quickly or could that be a sign that something is not right ? I tried setting LowDelay and KeepAlive socket options, but that didn't change anything. I've also checked the socket's state() and isValid() and they're good - although the latter also returns true when unconnected...
In an earlier version of the application, I closed and re-opened the connection before sending a request. This worked ok. I would prefer keeping the connection open though. Is that not a reasonable approach ? What is the 'canonical' way to to implement TCP network communication ? Just read/write or re-open every time ?
Does the way I read from the socket have any impact on how I can write to it ? Most sample code uses readAll(...) to get all available data; I read piece by piece as I need it and << to a QTextStream when writing...
Could this possibly be a bug in the Qt event loop ? I have observed that the output in the Qt Creator console created with QDebug() << ... almost always gets cut short, i.e. just stops. Sometimes some more output is printed when I shut down the application.
This is with the latest Qt 5.4.1 on Mac OS X 10.8, but the issue also occurs on Windows 7.
Update after the first answer and comments:
The test server is dead simple and was taken from the official Python SocketServer.TCPServer Example:
import SocketServer
class MyTCPHandler(SocketServer.StreamRequestHandler):
def handle(self):
request = self.rfile.readline().strip()
print "RX [%s]: %s" % (self.client_address[0], request)
response = self.processRequest(request)
print "TX [%s]: %s" % (self.client_address[0], response)
self.wfile.write(response)
def processRequest(self, message):
if message == 'request type 01':
return 'response type 01'
elif message == 'request type 02':
return 'response type 02'
if __name__ == "__main__":
server = SocketServer.TCPServer(('localhost', 12345), MyTCPHandler)
server.serve_forever()
The output I get is
RX [127.0.0.1]: request type 01
TX [127.0.0.1]: response type 01
Also, nothing happens when I re-send any message after this - which is not surprising as the socket was closed. Guess I'll have to figure out why it is closed...
Next update:
I've captured the network traffic using Wireshark and while all the network stuff doesn't really tell me a lot, I do see the first request and the response. Right after the client [ACK]nowledges the response, the server sends a Connection finish (FIN). I don't see the second request anywhere.
Last update:
I have posted a follow-up question at Python: SocketServer closes TCP connection unexpectedly.
Only the second request never seems to get sent :-(
I highly recommend running a program like WireShark and seeing what packets are actually getting sent and received across the network. (As it is, you can't know for sure whether the bug is on the client side or in the server, and that is the first thing you need to figure out)
do I need to "clear" the underlying socket in any way after reading ?
No.
is it possible / probable that not reading all the data the server has
sent me prevents me from writing ?
No.
why does the server close the connection ?
It's impossible to say without looking at the server's code.
Does it always do that so quickly or could that be a sign that
something is not right ?
Again, this would depend on how the server was written.
This worked ok. I would prefer keeping the connection open though. Is
that not a reasonable approach ?
Keeping the connection open is definitely a reasonable approach.
What is the 'canonical' way to to implement TCP network communication
? Just read/write or re-open every time ?
Neither was is canonical; it depends on what you are attempting to accomplish.
Does the way I read from the socket have any impact on how I can write
to it ?
No.
Could this possibly be a bug in the Qt event loop ?
That's extremely unlikely. The Qt code has been used for years by tens of thousands of programs, so any bug that serious would almost certainly have been found and fixed long ago. It's much more likely that either there is a bug in your client, or a bug in your server, or a mismatch between how you expect some API call to behave and how it actually behaves.
I have a C++ application that accepts TCP connections from client applications.
After a seemingly random time of running fine (days), it stops receiving followup messages from the clients and only sees the first message on each TCP connection. After a re-start all is fine again.
The trouble is, this only happens on the production server where I have to restart is as soon as it gets stuck and I have been uanble to reproduce this on a lab machine. None of the socket operations seems to return an error, that I would see in my logfile and the application is huge so I can't just post the relevant part here.
First messages keep coming through all the time, only subsequent messages aren't received after a while. Even when my application stops receiving the followup-messages, I can see them comming in with Wireshark.
Any ideas how I might find out what is happening ? What should I be looking for ?
Any config settings used here? In the past I have put a condition on a server accept to ignore messages after 50,000 have been processed. This was to prevent run-away situations in development. This code went live on one occasion without changing the config setting to 'allow infinite messages'. The result was exactly what you describe, ok for 2-3 days, then messages sent ok, but just ignored with no errors anywhere.
This may not be the case here, but I mention it as an example of where you may have to look.
How can I stop QNetworkRequest from buffering the entire contents of a QIODevice during a put/post to an HTTPS connection? It works fine when posting to HTTP but HTTPS causes the entire file to be read into memory before the post starts.
This isn't supported using the Qt classes. The reason is that Qt needs to know the total data length for the SSL headers. Chunked encoding is not supported from a send perspective. You can however roll your own - you'll need to create your own SSL header, then create your own chunks of SSL-encoded data.
I suggest you wrap this all up in your own class, so it's nicely re-usable (why not post it online?).
BTW, most of this information was taken from a recent thread on the Qt-interest mailing list - a thread on the 30th September 2009 discussed this exact problem.
You may probably have more success with Qt 4.6. It has some bugfixes regarding that.