Hi!
With Qt5 the QWindow class was introduced. I would like to store and restore
the complete
state and geometry of such objects.
I have working Qt4 code that saves and restores the geometry of QWidget based
windows
(using move(), resize(), windowState(), screenAt(), frameGeometry(),
More recent discussion about this problem can be also found at:
https://bugreports.qt.io/browse/QTBUG-58237
On Thu, 4 Apr 2019, 21:35 Jason H, wrote:
> Yes. Gone are the days of security from obscurity. Minutes after standing
> up a AWS ec2 instance i was getting scanned. Easy way to get rid
Yes. Gone are the days of security from obscurity. Minutes after standing up a
AWS ec2 instance i was getting scanned. Easy way to get rid of most of that is
don't be on a common port like 8080, port scans are less frequent but still
happen. Also maybe deploy a reverse proxy to validate
Quick test and it looks like this is it. When I start my server in SSL mode and
spam some ws connections at it I quickly loose ability to connect – even under
Windows.
What’s more, trying to connect to SSL server using ws protocol does not emit
any errors on the server side.
Can situation on
Wow, a P1 that was abandoned. https://codereview.qt-project.org/#/c/179030/
**facepalm**
Sent: Thursday, April 04, 2019 at 12:59 PM
From: "Jakub Narolewski"
To: "Jason H"
Cc: "interest@qt-project.org"
Subject: RE: [Interest] QWebSocketServer - server randomly stops
I just found this old report:
https://bugreports.qt.io/browse/QTBUG-57026
which sounds suspiciously similar to what I am observing. Hmm, I wonder if you
hit the jackpot writing earlier to use QTcpServer to initialize connections.
If I could still use SSL with
1. Add a slowloris attack to your fuzzer. Really.
2. "rejected" means something specific. The server does not reject your connection. Your client sends the RST packet.
The "long periods" could just be those first few [hundred] connections where everything goes right, but the slow
You jus did the same loop into your slot, the function I did made can be called
as slot to the connect you just told, I agree the
serial_port->waitForReadyRead(5); is not necessary, just often the transmission
have partial or bunch of data by small burst (USB VCOM) and was handy for me,
but it
First of all, thank you Jason for detailed analysis of the QWS' source and
tips about what can be done next.
I will of course report this to Qt JIRA as soon as I rule out error on my
end.
About the stuff with endsWith(), keep in mind that I have long periods of
time when server works just fine.
On Thu, Apr 4, 2019 at 5:46 PM Jérôme Godbout wrote:
> It relief the main thread from read data all the time and keep a good
> reactivity. The dedicated thread try to read and can wait until something
> come along and once it found something that can be parsed, it emit his own
> signal that the
Maybe you don't need another thread, just maybe an event loop (QEventLoop)?
> Sent: Thursday, April 04, 2019 at 10:43 AM
> From: "Jérôme Godbout"
> To: "Paolo Angelelli" , "interest@qt-project.org"
>
> Subject: Re: [Interest] Parsing data from serialport
>
> It relief the main thread from
That's NOT what I was going for!! I specifically said I have not tested any of
those theories. I ALSO said I have used it successfully. Do not let my
speculation hold you up. The more eyes (users) we have on this the better it
will be.
At this point Jakub should probably file a bug at
Am Do., 4. Apr. 2019 um 03:39 Uhr schrieb Hamish Moffatt <
ham...@risingsoftware.com>:
> On 3/4/19 6:34 pm, Roland Winklmeier wrote:
>
>
> Just for the record since breakpad was mentioned. There is now crashpad (
> https://chromium.googlesource.com/crashpad/crashpad/) which is the
> successor of
It relief the main thread from read data all the time and keep a good
reactivity. The dedicated thread try to read and can wait until something come
along and once it found something that can be parsed, it emit his own signal
that the main thread only have to handle into normal slot (will be
i was going to switch some codebase to websocket server, too,
but reading this lets me think again...
thanks ;)
Am Thu, 4 Apr 2019 16:33:19 +0200
schrieb "Jason H" :
> I looked at the private implementation of QWebSocketServer,
> QWebSocketServerPrivate.
>
> I haven't tested it, but there
I looked at the private implementation of QWebSocketServer, QWebSocketServerPrivate.
I haven't tested it, but there are a few concerns:
1. That for errorString(), it first checks if it doesn't have an error then returns the QTcpSocket errorString(). But if you just look at serverError()
What is the advantage of having such a continuous reading loop in a separate
thread?
I mean it as opposed to reacting to the readyRead() signal, and having a
while(canReadLine()) { ... } in the reacting
slot.
On Tue, 2 Apr 2019 22:01:49 +
Jérôme Godbout wrote:
> Make sure your reading
So, yeah, I was thinking of QTcpServer::incommingConnection(). That function is used in multithreadding because you use the descriptor to make a socket on the proper thread. Looks like QWebSocketServer is not multithreaded.
I've used Qt's websockets, and I've used QTcpServer extensively on
That's the thing. I already handle connections and disconnections in my
code - including logging relevant information.
When I implemented this I heavily based on the example that you linked to.
WSS communication is single threaded - only way to communicate with the
outside world from different
Thank you Jérome for the explanation. I implement it like you said.
Martin
Jérôme Godbout schrieb am Mi., 3. Apr. 2019, 15:12:
> Because you cannot unread data from the device and you have no guarantee
> that all the data will be present when you do read, you need a buffer since
> you need a
You probably want to read as far as I got with this series.
http://www.logikalsolutions.com/wordpress/information-technology/how-far-weve-come-pt-1/
Be sure to pull down the code for the various SerialKeypad implementations.
Here is a direct link to one of the zip files which was posted in
21 matches
Mail list logo
