fwm
Full Member
Posts: 105
|
Post by fwm on Jun 11, 2019 14:55:43 GMT -5
Right, yes I get it on the second point - makes sense, so nothing to worry about there I guess. Hope Rod's timer suggestion has helped move the issue forward Thanks Rod & Chris! Keith
|
|
|
Post by johnnyd on Jun 12, 2019 10:41:45 GMT -5
Hi, If you're using the mesock dll, it doesn't work with chr$(0) as I found out to my cost. It is used internally in the dll as an end-of-stream marker.
Just so you know!
John.
|
|
|
Post by Chris Iverson on Jun 12, 2019 11:06:18 GMT -5
Yup, mesock is good as long as you're only transmitting unencrypted text.
If you're transmitting binary data, it has to be encoded in some way, like Base64 or Base85.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Jun 13, 2019 10:44:10 GMT -5
I've been running my program and the server routine has been stuttering with the handshake routine and it's lack of a time limit. As I've thought about it more, I'm not sure a fixed 10-second limit on the server handshake would be a best fit for all applications. My program has other things to do as well as checking for an incoming conversation, so I'd rather be able to set a time of, say, 2 or 3 seconds, than it be hard-wired for 10 seconds each time.
What do you think?
Can we make it work so that the time limit can be set for both client and server handshakes?
Keith.
|
|
|
Post by Chris Iverson on Jun 13, 2019 10:55:00 GMT -5
Sure. In fact, once the code is in place to handle time limits on client-side handshakes, it'd be dead simple to modify the server-side stuff to include it as well.
However, I will point out that the 10 second handshake limit would only be active while a client is directly being negotiated with.
The check to see if any new connections are available is instant/non-blocking, and accepting a new connection is non-blocking.
Once you've accepted the connection, you're in active communication with the client. This is the part where you start exchanging data, either application data or a TLS handshake.
THIS is the part where the time limit would start to apply, and the only time you'd even come close to the 10 second limit is if the connection between you and the client breaks in a way that doesn't cause the socket to immediately abort. (Loss of network on your end, or the client closing the connection, both cause the recv() call to immediately return due to no longer having a socket to receive data from.)
Now, that 10 seconds will still cause a noticeable hiccup in your program if you happen to stumble into it(which is why I will add the option for server-side), but it shouldn't be something you'd see every time you check for connections.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Jun 27, 2019 18:06:02 GMT -5
I added the handshake timeout and the returning of the IP address to the code on GitHub, and updated the test-https-pfx.bas file to demo the updates.
I'm not an expert, and everything I have learned about C++ coding is from you (Chris), the MSDN online libraries and Stackflow (and a few others out there)... so sorry if it's crude and you want to tidy it up a bit but hopefully it gets the job done!
Keith
|
|
|
Post by Chris Iverson on Jun 27, 2019 21:30:07 GMT -5
I'll definitely take a look!
Sorry for the lack of progress, it's been extremely busy lately, and I haven't had much time to focus on other projects.
|
|