Attached is a User Control for SimpleSock. On the surface, a User Control is easier to use and more compact, but that is not the full story. I have hesitated to produce this control, because it makes a program more difficult to trouble shoot. This post will deal with the User Control itself. To find out more about the SimpleSock Class and it's associated module, see: https://www.vbforums.com/showthread....B6-Simple-Sock
The User Control contains SimpleSock.cls and modSocket.bas, but we cannot communicate directly with either of these. We must communicate with the User Control. So the User Control instantiates a dummy class which simply forwards the information to these 2 modules and visa versa.
Code:
'create an instance of SimpleSock
Set cmSocket = New SimpleSock
We declare all the "bridge" functions and properties in the control. The idea being that when the user calls a function in the control, we call the cmSocket function. When cmSocket raises an event we raise an event. When the user sets a property we set the cmSocket property. When the user retrieves a property we retrieve the cmSocket property and pass the result to the user.
To create the control, simply compile SIMPLSCK.ocx. Before using the control, I strongly suggest copying it to the \Windows\SysWOW64\ directory (\Windows\System32\ for 32 bit systems) with the rest of the OCX files. To enable the new control, start a new project and select the Components window. Then click on the Browse button, navigate to the "SysWOW64" directory, select the SIMPLSCK.ocx file, and click "OK". That will register the file and add it to the list of components. When you attempt to load the "TestSck" program, you should get a message that the version does not match. That is because the SID that I used to add the control to the test program does not match the one you just created. Let the system update it and save the project.
Using a Control may be convenient and space saving, but it comes at a price. In the IDE, it is a compiled program that you cannot debug directly. Even though there is a Public flag (DbgFlg) in the "modSocket" module, that when set to True will record the Debug.Print output to "socket.log", this is not as convenient as being able to step through the program. That is why I have hesitated making this control until now, and I would strongly suggest using the Class and Module directly in the early stages of program development. For convenience, a variable called "DebugFlag" has been added to the User Control, which sets this flag.
For the next part of the discussion, we need to understand how Winsock works. Winsock does not understand what a record is. It sends and receives data in packets, which generally maxes out around 1,500 bytes (less for WiFi). This is where it gets a little confusing. The actual transmitted packet length is governed by the Ethernet Maximum Transmission Unit (MTU), but the TCP stack can operate at sizes determined by the Maximum Segment Size (MSS). The MSS is 65,535 bytes (64K), but in the case of TLS 1.3, the MSS is 16,384 bytes (16K). Packets can come in at 1,500 bytes, but are not reported to you until the MSS is reached. Your program will generally send and receive data by record. The record length must be handled by you. The record length can be defined in a fixed or variable length header. HTML is a very old standard that uses variable length headers defined by a trailing double CrLf. The test program provided uses HTML.
The "DataArrival" and "EncrDataArrival" routines are re-entrant. That is to say that when one MSS is being processed by your program, Winsock can send more packets. I don't know the internal details of how it is handled, but it appears that a new instance of the subroutine is created for each event, but uses common variables if they have been declared global. If the incoming Winsock buffer is full, it will stop receiving data, but the class incoming buffer can be several times larger than a single record, so while you are processing one record, another one can already be started. This results in the speedy processing of data, but if you halt the program during processing, the class incoming buffer may not contain the expected data. A simple MsgBox falls into this category. In the test program, I have used "frmNotify" instead. It does not halt program execution. You can remove it by clicking on the "X", or hide it by clicking on the form itself (it will reappear 20 seconds later).
The sending of data has the opposite problem. If the Winsock outgoing buffer is full, Winsock will return a WSAEWOULDBLOCK error. TCPSend will intercept that error and suspend the TCPSend function. When the Winsock outgoing buffer is once again empty, Winsock will send an "FD_WRITE" and TCPSend will resume. The class buffer is only limited by the available memory. Data is added to the end of the class buffer, and Winsock takes data from the front of the class buffer in up to 64K chunks (the Winsock Buffer size), so you don't have to worry about that part. However, Winsock knows nothing about record lengths that are advertised in the record header. It could easily send the end of one record along with the start of the next record in the same packet. The problem is that encrypted records are limited to 16K (including Header & MAC). So you must break up sent encrypted records into 16K chunks with their own header & MAC.
The Test program supplied is configured like a browser to send HTML requests and receive HTML and binary responses, but it is far from performing like a real browser. To use the control for other purposes, remove the section that sends an HTML request after a connection is established. For secure connections, that code is found in the "HandShake" subroutine.
J.A. Coutts
Last edited by couttsj; Jul 20th, 2021 at 11:23 AM.
very good work.
I do not understand much its operation, due to lack of understanding.
It is like a replacement of the Winshock control of Dollarsoft.
You have more simpler examples.
very good work.
I do not understand much its operation, due to lack of understanding.
It is like a replacement of the Winshock control of Dollarsoft.
You have more simpler examples.
a greeting
PS: sorry my translation
NewSocket was based on CSocketMaster by Emiliano Scavuzzo, and CSocket by Oleg Gdalevich. The subclassing was based on WinSubHook2 by Paul Caton. The orginal CSocket & cSocket2 were designed to emulate the Microsoft Winsock Control. I added support for IPv6 with NewSocket, and did away with the use of variants in favor of ASCII strings, Unicode strings, and byte arrays.
SimpleSock and its associate SimpleServer were a complete rewrite to streamline the code, and is a bit different from the operation of the MS Winsock Control. SimpleSock.cls and modSocket.bas are very mature products, but SIMPLSCK.OCX incorporates both of these and is new.
The test program has been updated and the section of the description that deals with sending data has been modified to more correctly deal with the sending of large encrypted files. It had previously stated that care must be taken not to overflow the outgoing buffer, and this is not correct. The outgoing buffer handles itself. Winsock removes packet sized chunks of data from its own buffer, and SimpleSock transfers data from the front of it's own buffer in 64K chunks maximum (Winsock buffer size). If the Winsock buffer is full,Winsock returns a WSAEWOULDBLOCK error. TCPSend intercepts that error and suspends the sending of data. When the Winsock buffer is empty, it sends an "FD_WRITE" message and TCPSend is resumed.
Even though the test program does not need it in its present configuration, a routine called "eSend" was added to deal with the sending of large encrypted data. It breaks up encrypted data into 16K chunks (including Header & MAC), because that is the limit for encrypted data. This routine is to be used for all data after the Handshake routine.
Reply With Quote
Originally Posted by yokesee
