serverSocket w/ sslSocket

General
#1

I have a serverSocket, that should be properly configured and setup. I have the following in the addSocket event Handler:

[code] dim certFile as new folderItem
dim socketInstance as tcpFramework 'custom sslSocket class

socketInstance = new tcpFramework
certFile = getFolderItem(“c:\server\ssl.crt”)

socketInstance.certificateFile = certFile
socketInstance.secure = true

return socketInstance[/code]

The serverSocket is then initiated under the app.Run event using:

publicServerSocket.port = 443 publicServerSocket.listen

Problem I’m having is when one connection is made, it works fine. Once another connection from another device attempts, it immediately rejects the connection… resulting in an error 102 on the device. It’s only when I disconnect the previous connection, the other will work. Any ideas?

#2

BTW, let me add… the connection breaks before the .connected event handler on the either the server or the client device is initiated. I put print “connected” in both these events (both are console applications) and both print as expected on the first connection, but neither fire on the connections after that which get rejected.

#3

You forgot to set the connectiontype. Set it to TLSv1.

#4

Thanks Greg. I’ve added that. I made a few other changes, and got it working correctly. Now I have another issue:

For each new instance of an sslSocket, I have a property attached that is an msSqlDatabase. When I have 10 devices connected at once, and send an update via SQL to all devices at once… the instances are acting like everything is handled in a single thread, in queue-type fashion. One instance has to handle all the calls/updates/etc. to the database before it is released to the other device. I hope I’m making sense. I figured since each socket is it’s own instance, and each has it’s own property of the msSqlDatabase (constructed within the socket constructor using: myDb = new msSqlDatabase), then they would all work independently without having to wait on the other processes to complete.

#5

They still all run on the main thread. You could start a thread when the DataAvailable event fires though. That’s basically how the web framework does it.

#6

Will try that… thanks, Greg.

#7