|
Post by Chris Iverson on Mar 19, 2019 18:34:44 GMT -5
Not too much to report.
Added isDataAvailable() and isTLSDataAvailable(), to check if you have data ready to be read with Receive() or DecryptReceive().
EDIT: Also, I was able to use this DLL to successfully send an email message through Gmail.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Mar 24, 2019 5:04:33 GMT -5
Can you give some more info on the intended use for the two new functions? Is it a step closer towards running a server or is it for something else? Keith
|
|
|
Post by Chris Iverson on Mar 25, 2019 11:48:39 GMT -5
They're used to check if a given socket has data ready to read, so that a call to Receive() or DecryptReceive() won't block your application.
isDataAvailable(sock, msTimeout) is called with a socket received from Connect(), and the number of milliseconds(if any) you the function to wait before timing out.
It will return 1 if data is available, 0 if there is no data available, and -1 if there was an error. GetError() can be called to get the exact error code. If data is available, it can be retrieve with a call to Receive().
isTLSDataAvailable(hTLS, msTimeout) is called the exact same way, only with a TLS context instead of a socket. It's provided as a convenience, since you can do the same thing with the raw socket you opened before setting up security.
It has the same return codes, as well. The only difference is, if you get a response that data is available, you'll want to call DecryptReceive(), not just Receive().
Yes, they're a step on the way to implementing server sockets. I'm trying to come up with a way to wrap the functionality of the FD_SET, FD_ISSET, and select() functions, which let you pass in a set of reading and writing sockets to test if they're ready for reading/writing. This will make it FAR easier to manage multiple connections without blocking.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Mar 25, 2019 14:49:23 GMT -5
Sounds good I am excited to see if you can get it working as a listening server that can answer with a certificate etc. Keith.
|
|
|
Post by Chris Iverson on Apr 8, 2019 18:45:17 GMT -5
Well, I've got server TCP sockets up and running(creating sockets to listen on, not TLS yet).
I'm not happy with it yet, because for some reason, the internal call to winsock listen() is blocking, when all documentation says it shouldn't. (It only unblocks once a connection actually comes through; this is not how listen() is supposed to work. listen() just sets the socket into "listening" mode; accept() is what is supposed to block and wait for connections.) Once I get that figured out, I'll be happier with it.
EDIT: I've also split up the source code. Regular sockets stuff is in one file, and TLS stuff in another file.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Apr 9, 2019 3:41:47 GMT -5
So does that mean there will be two DLLs from now on?
|
|
|
Post by Chris Iverson on Apr 9, 2019 9:50:00 GMT -5
No, still one DLL. (I suppose I could make a sockets-only version of the DLL, for those who didn't want the TLS stuff, but the final binary size wouldn't be that much different, so you wouldn't be saving too much space by doing so.)
Splitting it up into different files will make that easier, but mainly, I did it for organization. The one CPP file was getting a bit too big to manage.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Apr 9, 2019 15:02:50 GMT -5
Personally, I don't like the idea of encouraging non-secure communication by releasing a non-TLS version. I think TLS should be part of the core... that's where this project came from, after all Any chance of adding in the Ping functionality we discussed some time ago? I concocted a working version, but only for IPv4. It's extremely useful for checking servers and devices are awake etc., and for analysing response times ahead of making an actual connection. Keith.
|
|
|
Post by Chris Iverson on Apr 9, 2019 15:20:34 GMT -5
Yeah, I agree on the TLS thing --- Oh, shoot, I'd honestly forgotten about that. Yeah, shouldn't be a problem. Checking response times is a decent idea, but for checking actual availability of servers, it may not be the best tool. ICMP traffic is blocked in a lot of places, so it's not a reliable measure, and the answer you get for "is the server there or not" can instantly be useless the next second, due to the very nature of unpredictable network issues. Using ping to check if a server is available doesn't help much if the server/connection goes down after your ping test. Still, it's a very useful troubleshooting tool, especially for devices on your local network, so I have no problem adding it.
|
|
|
Post by Chris Iverson on Apr 10, 2019 17:32:22 GMT -5
Fixed a bug with AcceptConnection() when attempting to work with multiple connections. Due to how I had the framework for Winsock set up, it was accidentally de-initializing Winsock out from under the listening socket.
To work around this, I had to add a couple of public functions to explicitly Initialize and End winsock. (I've added calls to them to the Open/Close DLL LB subroutines, so other code shouldn't need to be modified).
To avoid ambiguity, and make it clear that it was intended to be called multiple times if needed for each connection, I've renamed InitTLS()/EndTLS() to CreateTLSContext()/DestroyTLSContext(). I believe they are more accurate names.
I'm still not happy with the behavior of the listen sockets, but I'm still working on that.
Finally, I've added a PingHost function that should work for both IPv4 and IPv6 domains and addresses. It returns both a status code(in the case of echo replies that didn't fully succeed), and a millisecond ping count.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Apr 12, 2019 8:00:30 GMT -5
Sounds fantastic - I am about to download from GitHub and have a go at compiling to give it a test Keith
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Apr 12, 2019 16:43:02 GMT -5
I've compiled and tested and all seems good. Obviously I am not testing the newer functions related to running as a server and I will wait for you to finish your work on this and publish an example of how those functions work together The Ping function works great. I have modified it for myself so that the user can also specify the packet size as I had included this in the version I put together a few months ago. Thanks Chris
|
|
|
Post by Chris Iverson on Apr 12, 2019 17:29:57 GMT -5
That's not a bad idea. If you're willing to share the code, I'd be happy to incorporate it officially. Heck, you can send it in as a pull request, and you'll get added to the repo's official contributor history.
|
|
fwm
Full Member
Posts: 105
|
Post by fwm on Apr 12, 2019 18:24:49 GMT -5
Well I can't guarantee my coding skills are the best but I will do just that on GitHub!
Keith
|
|
|
Post by Chris Iverson on Apr 18, 2019 19:17:27 GMT -5
Well, I believe I've fixed the issue with the listen socket code, so I believe both client and server for basic sockets are done.
Right now the sample only takes one client and quits, but it shouldn't be hard to modify it to accept additional subsequent connections, and then multiple simultaneous connections.
|
|