From Xojo Documentation
Refer to the LastErrorCode property for a list of error codes and related class constants.
There are some instances where you would like the system to pick a port for you. These needs can range from needing a port for passive FTP file transfers, or perhaps you wrote a class to auto-discover other applications on the network and you would like to negotiate a port to connect over using TCP/IP. If you specify a Port of 0 and then call TCPSocket.Listen or UDPSocket.Connect, a random to open will be picked for you. Most often, these ports will be in the range of 49512 to 65535 (inclusive).
If you use this method to obtain an open port, then you probably need to use the following procedure to determine which port was chosen. After calling the Connect method or the Listen method of the TCPSocket class, you can check the Port property to see which port was assigned. This means that the port number will change from 0 to the port number that you are bound to.
There's another benefit checking the Port property. There is a hacking technique called port hijacking where the hacker steals a port out from under you. If this happens, checking the Port property will tell you if someone has hijacked the port. It can be a good idea (though paranoid) to periodically check to make sure the Port property returns a port that you expect to see. For instance, if you were listening on port 80 for HTTP connections, but the Port property says you're listening on port 2113, then something may be wrong.
The SendComplete event's parameter lets you know whether the transfer has completed or has been cancelled by returning True from the SendProgress event of the TCPSocket class. You can use this information to update different status variables, or alert the user of transfer success or failure. If the user aborted, this parameter is True, and if the send was completed, this value is False. The SendComplete event's parameter is always False for UDPSockets since there is not a SendProgress event for that class.
There are two different endian standards. Intel CPUs use "little" endianness. Sockets work with streams of data and do not change the endianness of the data you are transferring. This is fine in most cases, but if you are transferring binary data, such as from a BinaryStream or a MemoryBlock, you will want to ensure that the endianness matches from server to client regardless of what platform you are on. You can do this by setting the LittleEndian property on MemoryBlocks or BinaryStreams to the same value for your client and your server. Failure to ensure that the endianness is consistent will result in a possible byte-order conflict in your application. You can use the TargetBigEndian and TargetLittleEndian constants to determine the endian standard for the platform on which your app is running.