Socket PureBasic Reference Documentation

Socket

Current Version: 10.0.0

TCP socket component with SSL capability. Supports both asynchronous connect, accept, send, and read operations in all programming languages. The ActiveX and .NET socket components also include heartbeat, completion, and other events when blocking methods are called. DNS is supported in both synchronous and asynchronous modes. Supports the ability to abort all operations: connect, accept, send, receive, DNS lookups, etc. prior to completion.

Object Creation

obj.i = CkSocket::ckCreate()

; Make sure to dispose of the object when finished like this:
CkSocket::ckDispose(obj);

Properties

AbortCurrent
Declare.i ckAbortCurrent(obj.i)
Declare setCkAbortCurrent(obj.i, value.i)
Introduced in version 9.5.0.58

When set to 1, causes the currently running method to abort. Methods that always finish quickly (i.e.have no length file operations or network communications) are not affected. If no method is running, then this property is automatically reset to 0 when the next method is called. When the abort occurs, this property is reset to 0. Both synchronous and asynchronous method calls can be aborted. (A synchronous method call could be aborted by setting this property from a separate thread.)

top
AcceptFailReason
Declare.i ckAcceptFailReason(obj.i) ; (read-only)
Introduced in version 9.5.0.50

If a AcceptNextConnection method fails, this property can be checked to determine the reason for failure.

Note: If accepting a TLS connection, then this property can also have any of the values listed for the ReceiveFailReason and SendFailReason properties (because the TLS handshake involves sending/receiving on the initial TCP socket).

Possible values are:

0 = Success
1 = An async operation is  in progress.
3 = An unspecified internal failure, perhaps out-of-memory, caused the failure.
5 = Timeout.  No connections were accepted in the amount of time alotted.
6 = The receive was aborted by the application in an event callback.
9 = An unspecified fatal socket error occurred (less common).
20 = Must first bind and listen on a port.
99 = The component is not unlocked.

Errors Relating to the SSL/TLS Handshake:
100 = TLS internal error.
102 = Unexpected handshake message.
109 = Failed to read handshake messages.
114 = Failed to send change cipher spec handshake message.
115 = Failed to send finished handshake message.
116 = Client's Finished message is invalid.
117 = Unable to agree on TLS protocol version.
118 = Unable to agree on a cipher spec.
119 = Failed to read the client's hello message.
120 = Failed to send handshake messages.
121 = Failed to process client cert message.
122 = Failed to process client cert URL message.
123 = Failed to process client key exchange message.
124 = Failed to process certificate verify message.
125 = Received and rejected an SSL 2.0 connection attempt.

top
AlpnProtocol
Declare.s ckAlpnProtocol(obj.i)
Declare setCkAlpnProtocol(obj.i, value.s)
Introduced in version 9.5.0.82

For TLS connections. Can be set to the name of an application layer protocol. This causes the ALPN extension to be added to the TLS ClientHello with the given ALPN protocol name.

top
BandwidthThrottleDown
Declare.i ckBandwidthThrottleDown(obj.i)
Declare setCkBandwidthThrottleDown(obj.i, value.i)
Introduced in version 9.5.0.49

If non-zero, limits (throttles) the receiving bandwidth to approximately this maximum number of bytes per second. The default value of this property is 0.

top
BandwidthThrottleUp
Declare.i ckBandwidthThrottleUp(obj.i)
Declare setCkBandwidthThrottleUp(obj.i, value.i)
Introduced in version 9.5.0.49

If non-zero, limits (throttles) the sending bandwidth to approximately this maximum number of bytes per second. The default value of this property is 0.

More Information and Examples
top
BigEndian
Declare.i ckBigEndian(obj.i)
Declare setCkBigEndian(obj.i, value.i)

Applies to the SendCount and ReceiveCount methods. If BigEndian is set to 1 (the default) then the 4-byte count is in big endian format. Otherwise it is little endian.

top
ClientIpAddress
Declare.s ckClientIpAddress(obj.i)
Declare setCkClientIpAddress(obj.i, value.s)

The IP address to use for computers with multiple network interfaces or IP addresses. For computers with a single network interface (i.e. most computers), this property should not be set. For multihoming computers, the default IP address is automatically used if this property is not set.

The IP address is a string such as in dotted notation using numbers, not domain names, such as "165.164.55.124".

More Information and Examples
top
ClientPort
Declare.i ckClientPort(obj.i)
Declare setCkClientPort(obj.i, value.i)

Normally left at the default value of 0, in which case a unique port is assigned with a value between 1024 and 5000. This property would only be changed if it is specifically required. For example, one customer's requirements are as follows:

"I have to connect to a Siemens PLC IP server on a technical network. This machine expects that I connect to its server from a specific IP address using a specific port otherwise the build in security disconnect the IP connection."

top
ConnectFailReason
Declare.i ckConnectFailReason(obj.i) ; (read-only)

If the Connect method fails, this property can be checked to determine the reason for failure.

Possible values are:

0 = success

Normal (non-SSL) sockets:
1 = empty hostname
2 = DNS lookup failed
3 = DNS timeout
4 = Aborted by application.
5 = Internal failure.
6 = Connect Timed Out
7 = Connect Rejected (or failed for some other reason)

SSL/TLS:
100 = TLS internal error.
101 = Failed to send client hello.
102 = Unexpected handshake message.
103 = Failed to read server hello.
104 = No server certificate.
105 = Unexpected TLS protocol version.
106 = Server certificate verify failed (the server certificate is expired or the cert's signature verification failed).
107 = Unacceptable TLS protocol version.
108 = App-defined server certificate requirements failure.
109 = Failed to read handshake messages.
110 = Failed to send client certificate handshake message.
111 = Failed to send client key exchange handshake message.
112 = Client certificate's private key not accessible.
113 = Failed to send client cert verify handshake message.
114 = Failed to send change cipher spec handshake message.
115 = Failed to send finished handshake message.
116 = Server's Finished message is invalid.

top
DebugLogFilePath
Declare.s ckDebugLogFilePath(obj.i)
Declare setCkDebugLogFilePath(obj.i, value.s)

If set to a file path, causes each Chilkat method or property call to automatically append it's LastErrorText to the specified log file. The information is appended such that if a hang or crash occurs, it is possible to see the context in which the problem occurred, as well as a history of all Chilkat calls up to the point of the problem. The VerboseLogging property can be set to provide more detailed information.

This property is typically used for debugging the rare cases where a Chilkat method call hangs or generates an exception that halts program execution (i.e. crashes). A hang or crash should generally never happen. The typical causes of a hang are:

  1. a timeout related property was set to 0 to explicitly indicate that an infinite timeout is desired,
  2. the hang is actually a hang within an event callback (i.e. it is a hang within the application code), or
  3. there is an internal problem (bug) in the Chilkat code that causes the hang.

More Information and Examples
top
ElapsedSeconds
Declare.i ckElapsedSeconds(obj.i) ; (read-only)

Contains the number of seconds since the last call to StartTiming, otherwise contains 0. (The StartTiming method and ElapsedSeconds property is provided for convenience.)

top
HttpProxyAuthMethod
Declare.s ckHttpProxyAuthMethod(obj.i)
Declare setCkHttpProxyAuthMethod(obj.i, value.s)

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy authentication method name. Valid choices are "Basic" or "NTLM".

top
HttpProxyDomain
Declare.s ckHttpProxyDomain(obj.i)
Declare setCkHttpProxyDomain(obj.i, value.s)

The NTLM authentication domain (optional) if NTLM authentication is used.

top
HttpProxyForHttp
Declare.i ckHttpProxyForHttp(obj.i)
Declare setCkHttpProxyForHttp(obj.i, value.i)
Introduced in version 9.5.0.70

If this connection is effectively used to send HTTP requests, then set this property to 1 when using an HTTP proxy. The default value of this property is 0.

This is because an HTTP proxy used for other protocols (IMAP, SMTP, SSH, FTP, etc.) can require some internal differences in behavior (i.e. how we do things).

For example, the Chilkat REST object can use this socket object's connection via the UseConnection method. This is a case where we know the proxied connection is for the HTTP protocol. Therefore we should set this property to 1. (See the example below.)

More Information and Examples
top
HttpProxyHostname
Declare.s ckHttpProxyHostname(obj.i)
Declare setCkHttpProxyHostname(obj.i, value.s)

If an HTTP proxy is to be used, set this property to the HTTP proxy hostname or IPv4 address (in dotted decimal notation).

top
HttpProxyPassword
Declare.s ckHttpProxyPassword(obj.i)
Declare setCkHttpProxyPassword(obj.i, value.s)

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy password.

top
HttpProxyPort
Declare.i ckHttpProxyPort(obj.i)
Declare setCkHttpProxyPort(obj.i, value.i)

If an HTTP proxy is to be used, set this property to the HTTP proxy port number. (Two commonly used HTTP proxy ports are 8080 and 3128.)

top
HttpProxyUsername
Declare.s ckHttpProxyUsername(obj.i)
Declare setCkHttpProxyUsername(obj.i, value.s)

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy login name.

top
IsConnected
Declare.i ckIsConnected(obj.i) ; (read-only)

Returns 1 if the socket is connected. Otherwise returns 0.

Note: In general, this property indicates the last known state of the socket. For example, if the socket is connected, and your application does not read or write the socket, then IsConnected will remain 1. This property is updated when your application tries to read or write and discovers that the socket is no longer connected. It is also updated if your application explicitly closes the socket.

top
KeepAlive
Declare.i ckKeepAlive(obj.i)
Declare setCkKeepAlive(obj.i, value.i)
Introduced in version 9.5.0.49

Controls whether the SO_KEEPALIVE socket option is used for the underlying TCP/IP socket. The default value is 1.

top
KeepSessionLog
Declare.i ckKeepSessionLog(obj.i)
Declare setCkKeepSessionLog(obj.i, value.i)

Controls whether socket (or SSL) communications are logged to the SessionLog string property. To turn on session logging, set this property = 1, otherwise set to 0 (which is the default value).

More Information and Examples
top
LastErrorHtml
Declare.s ckLastErrorHtml(obj.i) ; (read-only)

Provides information in HTML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastErrorText
Declare.s ckLastErrorText(obj.i) ; (read-only)

Provides information in plain-text format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastErrorXml
Declare.s ckLastErrorXml(obj.i) ; (read-only)

Provides information in XML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastMethodFailed
Declare.i ckLastMethodFailed(obj.i) ; (read-only)

1 if the last method called on this object failed. This provides an easier (less confusing) way of determining whether a method such as ReceiveBytes succeeded or failed.

top
LastMethodSuccess
Declare.i ckLastMethodSuccess(obj.i)
Declare setCkLastMethodSuccess(obj.i, value.i)

Indicate whether the last method call succeeded or failed. A value of 1 indicates success, a value of 0 indicates failure. This property is automatically set for method calls. It is not modified by property accesses. The property is automatically set to indicate success for the following types of method calls:

  • Any method that returns a string.
  • Any method returning a Chilkat object, binary bytes, or a date/time.
  • Any method returning a standard boolean status value where success = 1 and failure = 0.
  • Any method returning an integer where failure is defined by a return value less than zero.

Note: Methods that do not fit the above requirements will always set this property equal to 1. For example, a method that returns no value (such as a "void" in C++) will technically always succeed.

top
ListenIpv6
Declare.i ckListenIpv6(obj.i)
Declare setCkListenIpv6(obj.i, value.i)

If set to 1, then a socket that listens for incoming connections (via the BindAndList and AcceptNextConnection method calls) will use IPv6 and not IPv4. The default value is 0 for IPv4.

top
ListenPort
Declare.i ckListenPort(obj.i) ; (read-only)
Introduced in version 9.5.0.59

The BindAndListen method will find a random unused port to listen on if you bind to port 0. This chosen listen port is available via this property.

top
LocalIpAddress
Declare.s ckLocalIpAddress(obj.i) ; (read-only)

The local IP address for a bound or connected socket.

top
LocalPort
Declare.i ckLocalPort(obj.i) ; (read-only)

The local port for a bound or connected socket.

top
MaxReadIdleMs
Declare.i ckMaxReadIdleMs(obj.i)
Declare setCkMaxReadIdleMs(obj.i, value.i)

The maximum number of milliseconds to wait on a socket read operation while no additional data is forthcoming. To wait indefinitely, set this property to 0. The default value is 0.

This applies to all methods that read from the socket, and also any other methods that read on the socket, such as SshOpenTunnel.

top
MaxSendIdleMs
Declare.i ckMaxSendIdleMs(obj.i)
Declare setCkMaxSendIdleMs(obj.i, value.i)

The maximum number of milliseconds to wait for the socket to become writeable on a socket write operation. To wait indefinitely, set this property to 0. The default value is 0.

top
MyIpAddress
Declare.s ckMyIpAddress(obj.i) ; (read-only)

The local IP address of the local computer. For multi-homed computers (i.e. computers with multiple IP adapters) this property returns the default IP address.

Note: This will be the internal IP address, not an external IP address. (For example, if your computer is on a LAN, it is likely to be an IP address beginning with "192.168.".

Important: Use LocalIpAddress and LocalIpPort to get the local IP/port for a bound or connected socket.

More Information and Examples
top
NumBytesAvailable
Declare.i ckNumBytesAvailable(obj.i) ; (read-only)
Introduced in version 9.5.0.94

Returns the number of bytes that are immediately available for reading on a connected socket. For TLS connections, this includes the overhead for TLS protocol records.

top
NumReceivedClientCerts
Declare.i ckNumReceivedClientCerts(obj.i) ; (read-only)

If the socket is the server-side of an SSL/TLS connection, the property represents the number of client-side certificates received during the SSL/TLS handshake (i.e. connection process). Each client-side cert may be retrieved by calling the GetReceivedClientCert method and passing an integer index value from 0 to N-1, where N is the number of client certs received.

Note: A client only sends a certificate if 2-way SSL/TLS is required. In other words, if the server demands a certificate from the client.

Important: This property should be examined on the socket object that is returned by AcceptNextConnection.

top
NumSocketsInSet
Declare.i ckNumSocketsInSet(obj.i) ; (read-only)

If this socket is a "socket set", then NumSocketsInSet returns the number of sockets contained in the set. A socket object can become a "socket set" by calling the TakeSocket method on one or more connected sockets. This makes it possible to select for reading on the set (i.e. wait for data to arrive from any one of multiple sockets). See the following methods and properties for more information: TakeSocket, SelectorIndex, SelectorReadIndex, SelectorWriteIndex, SelectForReading, SelectForWriting.

More Information and Examples
top
NumSslAcceptableClientCAs
Declare.i ckNumSslAcceptableClientCAs(obj.i) ; (read-only)

If connected as an SSL/TLS client to an SSL/TLS server where the server requires a client-side certificate for authentication, then this property contains the number of acceptable certificate authorities sent by the server during connection establishment handshake. The GetSslAcceptableClientCaDn method may be called to get the Distinguished Name (DN) of each acceptable CA.

top
ObjectId
Declare.i ckObjectId(obj.i) ; (read-only)

Each socket object is assigned a unique object ID. This ID is passed in event callbacks to allow your application to associate the event with the socket object.

top
PreferIpv6
Declare.i ckPreferIpv6(obj.i)
Declare setCkPreferIpv6(obj.i, value.i)

If the socket is used for initiating connections, then this property behaves as follows: When connecting to a domain name, the automatic DNS lookup could result in both IPv4 and IPv6 addresses. If this property is 1, then the IPv6 address is chosen, otherwise the IPv4 address is chosen. The default value of this property is 0, which will choose IPv4 over IPv6.

If the socket is used for listening and receiving connections, then this property controls whether to listen on IPv6 or IPv4. If this property is 1, then IPv6 connections can be accepted, otherwise only IPv4 connections can be accepted. (Note: Chilkat was updated in v9.5.0.97 to enable "dual-stack" support, where a server can handle both IPv6 and IPv4 traffic using a single socket. Prior to v9.5.0.97, setting this property to 1 had the effect that only IPv6 connections could be accepted.)

top
RcvBytesPerSec
Declare.i ckRcvBytesPerSec(obj.i) ; (read-only)
Introduced in version 9.5.0.78

Returns the cumulative receive rate in bytes per second. The measurement includes the overhead bytes for protocols such as TLS or SSH tunneling. For example, if 1000 application bytes are received, the actual number of raw bytes received on a TLS connection is greater. This property measures the actual number of raw bytes received in a given time period. The ResetPerf method can be called to reset this property value and to begin the performance measurement afresh.

top
ReceivedCount
Declare.i ckReceivedCount(obj.i)
Declare setCkReceivedCount(obj.i, value.i)

Any method that receives data will increase the value of this property by the number of bytes received. The application may reset this property to 0 at any point. It is provided as a way to keep count of the total number of bytes received on a socket connection, regardless of which method calls are used to receive the data.

Note: The ReceivedCount may be larger than the number of bytes returned by some methods. For methods such as ReceiveUntilMatch, the excess received on the socket (beyond the match), is buffered by Chilkat for subsequent method calls. The ReceivedCount is updated based on the actual number of bytes received on the underlying socket in real-time. (The ReceivedCount does not include the overhead bytes associated with the TLS and/or SSH protocols.

top
ReceivedInt
Declare.i ckReceivedInt(obj.i)
Declare setCkReceivedInt(obj.i, value.i)
Introduced in version 9.5.0.50

Contains the last integer received via a call to ReceiveByte, ReceiveInt16, or ReceiveInt32.

top
ReceiveFailReason
Declare.i ckReceiveFailReason(obj.i) ; (read-only)
Introduced in version 9.5.0.49

If a Receive method fails, this property can be checked to determine the reason for failure.

Possible values are:

0 = Success
1 = An async receive operation is already in progress.
2 = The socket is not connected, such as if it was never connected, or if the connection was previously lost.
3 = An unspecified internal failure, perhaps out-of-memory, caused the failure.
4 = Invalid parameters were passed to the receive method call.
5 = Timeout.  Data stopped arriving for more than the amount of time specified by the MaxReadIdleMs property.
6 = The receive was aborted by the application in an event callback.
7 = The connection was lost -- the remote peer reset the connection. (The connection was forcibly closed by the peer.)
8 = An established connection was aborted by the software in your host machine. (See https://www.chilkatsoft.com/p/p_299.asp )
9 = An unspecified fatal socket error occurred (less common).
10 = The connection was closed by the peer.

top
ReceivePacketSize
Declare.i ckReceivePacketSize(obj.i)
Declare setCkReceivePacketSize(obj.i, value.i)

The number of bytes to receive at a time (internally). This setting has an effect on methods such as ReadBytes and ReadString where the number of bytes to read is not explicitly specified. The default value is 4096.

top
RemoteIpAddress
Declare.s ckRemoteIpAddress(obj.i) ; (read-only)

When a socket is connected, the remote IP address of the connected peer is available in this property.

top
RemotePort
Declare.i ckRemotePort(obj.i) ; (read-only)

When a socket is connected, the remote port of the connected peer is available in this property.

top
RequireSslCertVerify
Declare.i ckRequireSslCertVerify(obj.i)
Declare setCkRequireSslCertVerify(obj.i, value.i)

If 1, then the SSL/TLS client will verify the server's SSL certificate. The certificate is expired, or if the cert's signature is invalid, the connection is not allowed. The default value of this property is 0.

top
SelectorIndex
Declare.i ckSelectorIndex(obj.i)
Declare setCkSelectorIndex(obj.i, value.i)

If this socket contains a collection of connected sockets (i.e. it is a "socket set") then method calls and property gets/sets are routed to the contained socket indicated by this property. Indexing begins at 0. See the TakeSocket method and SelectForReading method for more information.

More Information and Examples
top
SelectorReadIndex
Declare.i ckSelectorReadIndex(obj.i)
Declare setCkSelectorReadIndex(obj.i, value.i)

When SelectForReading returns a number greater than 0 indicating that 1 or more sockets are ready for reading, this property is used to select the socket in the "ready set" for reading. See the example below:

More Information and Examples
top
SelectorWriteIndex
Declare.i ckSelectorWriteIndex(obj.i)
Declare setCkSelectorWriteIndex(obj.i, value.i)

When SelectForWriting returns a number greater than 0 indicating that one or more sockets are ready for writing, this property is used to select the socket in the "ready set" for writing.

top
SendBytesPerSec
Declare.i ckSendBytesPerSec(obj.i) ; (read-only)
Introduced in version 9.5.0.78

Returns the cumulative send rate in bytes per second. The measurement includes the overhead bytes for protocols such as TLS or SSH tunneling. For example, if 1000 application bytes are sent, the actual number of raw bytes sent on a TLS connection is greater. This property measures the actual number of raw bytes sent in a given time period. The ResetPerf method can be called to reset this property value and to begin the performance measurement afresh.

top
SendFailReason
Declare.i ckSendFailReason(obj.i) ; (read-only)
Introduced in version 9.5.0.49

If a Send method fails, this property can be checked to determine the reason for failure.

Possible values are:

0 = Success
1 = An async receive operation is already in progress.
2 = The socket is not connected, such as if it was never connected, or if the connection was previously lost.
3 = An unspecified internal failure, perhaps out-of-memory, caused the failure.
4 = Invalid parameters were passed to the receive method call.
5 = Timeout.  Data stopped arriving for more than the amount of time specified by the MaxReadIdleMs property.
6 = The receive was aborted by the application in an event callback.
7 = The connection was lost -- the remote peer reset the connection. (The connection was forcibly closed by the peer.)
8 = An established connection was aborted by the software in your host machine. (See https://www.chilkatsoft.com/p/p_299.asp )
9 = An unspecified fatal socket error occurred (less common).
10 = The connection was closed by the peer.
11 = Decoding error (possible in SendString when coverting to the StringCharset, or in SendBytesENC).

top
SendPacketSize
Declare.i ckSendPacketSize(obj.i)
Declare setCkSendPacketSize(obj.i, value.i)

The number of bytes to send at a time (internally). This can also be though of as the "chunk size". If a large amount of data is to be sent, the data is sent in chunks equal to this size in bytes. The default value is 65535. (Note: This only applies to non-SSL/TLS connections. SSL and TLS have their own pre-defined packet sizes.)

top
SessionLog
Declare.s ckSessionLog(obj.i) ; (read-only)

Contains a log of the bytes sent and received on this socket. The KeepSessionLog property must be set to 1 for logging to occur.

More Information and Examples
top
SessionLogEncoding
Declare.s ckSessionLogEncoding(obj.i)
Declare setCkSessionLogEncoding(obj.i, value.s)

Controls how the data is encoded in the SessionLog. Possible values are "esc" and "hex". The default value is "esc".

When set to "hex", the bytes are encoded as a hexidecimalized string. The "esc" encoding is a C-string like encoding, and is more compact than hex if most of the data to be logged is text. Printable us-ascii chars are unmodified. Common "C" control chars are represented as "\r", "\n", "\t", etc. Non-printable and byte values greater than 0x80 are escaped using a backslash and hex encoding: \xHH. Certain printable chars are backslashed: SPACE, double-quote, single-quote, etc.

More Information and Examples
top
SniHostname
Declare.s ckSniHostname(obj.i)
Declare setCkSniHostname(obj.i, value.s)
Introduced in version 9.5.0.82

Specifies the SNI hostname to be used in the TLS ClientHello. This property is only needed when the domain is specified via a dotted IP address and an SNI hostname is desired. (Normally, Chilkat automatically uses the domain name in the SNI hostname TLS ClientHello extension.)

top
SocksHostname
Declare.s ckSocksHostname(obj.i)
Declare setCkSocksHostname(obj.i, value.s)

The SOCKS4/SOCKS5 hostname or IPv4 address (in dotted decimal notation). This property is only used if the SocksVersion property is set to 4 or 5).

top
SocksPassword
Declare.s ckSocksPassword(obj.i)
Declare setCkSocksPassword(obj.i, value.s)

The SOCKS5 password (if required). The SOCKS4 protocol does not include the use of a password, so this does not apply to SOCKS4.

top
SocksPort
Declare.i ckSocksPort(obj.i)
Declare setCkSocksPort(obj.i, value.i)

The SOCKS4/SOCKS5 proxy port. The default value is 1080. This property only applies if a SOCKS proxy is used (if the SocksVersion property is set to 4 or 5).

top
SocksUsername
Declare.s ckSocksUsername(obj.i)
Declare setCkSocksUsername(obj.i, value.s)

The SOCKS4/SOCKS5 proxy username. This property is only used if the SocksVersion property is set to 4 or 5).

top
SocksVersion
Declare.i ckSocksVersion(obj.i)
Declare setCkSocksVersion(obj.i, value.i)

SocksVersion May be set to one of the following integer values:

0 - No SOCKS proxy is used. This is the default.
4 - Connect via a SOCKS4 proxy.
5 - Connect via a SOCKS5 proxy.

top
SoRcvBuf
Declare.i ckSoRcvBuf(obj.i)
Declare setCkSoRcvBuf(obj.i, value.i)

Sets the receive buffer size socket option. Normally, this property should be left unchanged. The default value is 4194304.

This property can be increased if download performance seems slow. It is recommended to be a multiple of 4096.

top
SoReuseAddr
Declare.i ckSoReuseAddr(obj.i)
Declare setCkSoReuseAddr(obj.i, value.i)

Sets the SO_REUSEADDR socket option for a socket that will bind to a port and listen for incoming connections. The default value is 1, meaning that the SO_REUSEADDR socket option is set. If the socket option must be unset, set this property equal to 0 prior to calling BindAndListen or InitSslServer.

top
SoSndBuf
Declare.i ckSoSndBuf(obj.i)
Declare setCkSoSndBuf(obj.i, value.i)

Sets the send buffer size socket option. Normally, this property should be left unchanged. The default value is 262144.

This property can be increased if upload performance seems slow. It is recommended to be a multiple of 4096. Testing with sizes such as 512K and 1MB is reasonable.

top
Ssl
Declare.i ckSsl(obj.i)
Declare setCkSsl(obj.i, value.i)

Set this property to 1 if SSL/TLS is required for accepted connections (AcceptNextConnection). The default value is 0.

Note: This property should have been more precisely named "RequireSslClient". It is a property that if set to 1, requires all accepted connections use SSL/TLS. If a client attempts to connect but cannot establish the TLS connection, then it is not accepted. This property is not meant to reflect the current state of the connection.

The TlsVersion property shows the current or last negotiated TLS version of the connection. The TlsVersion will be empty for a non-SSL/TLS connection.

top
SslAllowedCiphers
Declare.s ckSslAllowedCiphers(obj.i)
Declare setCkSslAllowedCiphers(obj.i, value.s)
Introduced in version 9.5.0.48

Provides a means for setting a list of ciphers that are allowed for SSL/TLS connections. The default (empty string) indicates that all implemented ciphers are possible. The TLS ciphers supported in Chilkat v9.5.0.55 and later are:

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
To restrict SSL/TLS connections to one or more specific ciphers, set this property to a comma-separated list of ciphers such as "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384". The order should be in terms of preference, with the preferred algorithms listed first. (Note that the client cannot specifically choose the algorithm is picked because it is the server that chooses. The client simply provides the server with a list from which to choose.)

The property can also disallow connections with servers having certificates with RSA keys less than a certain size. By default, server certificates having RSA keys of 512 bits or greater are allowed. Add the keyword "rsa1024" to disallow connections with servers having keys smaller than 1024 bits. Add the keyword "rsa2048" to disallow connections with servers having keys smaller than 2048 bits.

Note: Prior to Chilkat v9.5.0.55, it was not possible to explicitly list allowed cipher suites. The deprecated means for indicating allowed ciphers was both incomplete and unprecise. For example, the following keywords could be listed to allow matching ciphers: "aes256-cbc", "aes128-cbc", "3des-cbc", and "rc4". These keywords will still be recognized, but programs should be updated to explicitly list the allowed ciphers.

secure-renegotiation: Starting in Chilkat v9.5.0.55, the keyword "secure-renegotiation" may be added to require that all renegotions be done securely (as per RFC 5746).

best-practices: Starting in Chilkat v9.5.0.55, this property may be set to the single keyword "best-practices". This will allow ciphers based on the current best practices. As new versions of Chilkat are released, the best practices may change. Changes will be noted here. The current best practices are:

  • If the server uses an RSA key, it must be 1024 bits or greater.
  • All renegotations must be secure renegotiations.
  • All ciphers using RC4, DES, or 3DES are disallowed.

Example: The following string would restrict to 2 specific cipher suites, require RSA keys to be 1024 bits or greater, and require secure renegotiations: "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, rsa1024, secure-renegotiation"

top
SslProtocol
Declare.s ckSslProtocol(obj.i)
Declare setCkSslProtocol(obj.i, value.s)

Selects the secure protocol to be used for secure (SSL/TLS) connections. Possible values are:

default
TLS 1.3
TLS 1.2
TLS 1.1
TLS 1.0
SSL 3.0
TLS 1.3 or higher
TLS 1.2 or higher
TLS 1.1 or higher
TLS 1.0 or higher
The default value is "default" which will choose the, which allows for the protocol to be selected dynamically at runtime based on the requirements of the server. Choosing an exact protocol will cause the connection to fail unless that exact protocol is negotiated. It is better to choose "X or higher" than an exact protocol. The "default" is effectively "SSL 3.0 or higher".

Note: Chilkat does not yet implement TLS 1.3 for the server-side of the TLS protocol. Chilkat can do TLS 1.3 on the client-side, such as when connecting to servers, but not when acting as a server and receiving/accepting TLS connections.

More Information and Examples
top
StringCharset
Declare.s ckStringCharset(obj.i)
Declare setCkStringCharset(obj.i, value.s)

A charset such as "utf-8", "windows-1252", "Shift_JIS", "iso-8859-1", etc. Methods for sending and receiving strings will use this charset as the encoding. Strings sent on the socket are first converted (if necessary) to this encoding. When reading, it is assumed that the bytes received are converted FROM this charset if necessary. This ONLY APPLIES TO THE SendString and ReceiveString methods. The default value is "ansi".

top
TcpNoDelay
Declare.i ckTcpNoDelay(obj.i)
Declare setCkTcpNoDelay(obj.i, value.i)

Controls whether the TCP_NODELAY socket option is used for the underlying TCP/IP socket. The default value is 0. Setting the value to 1 disables the Nagle algorithm and allows for better performance when small amounts of data are sent on the socket connection.

top
TlsCipherSuite
Declare.s ckTlsCipherSuite(obj.i) ; (read-only)
Introduced in version 9.5.0.49

Contains the current or last negotiated TLS cipher suite. If no TLS connection has yet to be established, or if a connection as attempted and failed, then this will be empty. A sample cipher suite string looks like this: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.

top
TlsPinSet
Declare.s ckTlsPinSet(obj.i)
Declare setCkTlsPinSet(obj.i, value.s)
Introduced in version 9.5.0.55

Specifies a set of pins for Public Key Pinning for TLS connections. This property lists the expected SPKI fingerprints for the server certificates. If the server's certificate (sent during the TLS handshake) does not match any of the SPKI fingerprints, then the TLS handshake is aborted and the connection fails. The format of this string property is as follows:

hash_algorithm, encoding, SPKI_fingerprint_1, SPKI_fingerprint_2, ...
For example, the following string specifies a single sha256 base64-encoded SPKI fingerprint:
"sha256, base64, lKg1SIqyhPSK19tlPbjl8s02yChsVTDklQpkMCHvsTE="
This example specifies two SPKI fingerprints:
"sha256, base64, 4t37LpnGmrMEAG8HEz9yIrnvJV2euVRwCLb9EH5WZyI=, 68b0G5iqMvWVWvUCjMuhLEyekM5729PadtnU5tdXZKs="
Any of the following hash algorithms are allowed:.sha1, sha256, sha384, sha512, md2, md5, haval, ripemd128, ripemd160,ripemd256, or ripemd320.

The following encodings are allowed: base64, hex, and any of the encodings indicated in the link below.

More Information and Examples
top
TlsVersion
Declare.s ckTlsVersion(obj.i) ; (read-only)
Introduced in version 9.5.0.49

Contains the current or last negotiated TLS protocol version. If no TLS connection has yet to be established, or if a connection as attempted and failed, then this will be empty. Possible values are "SSL 3.0", "TLS 1.0", "TLS 1.1", "TLS 1.2", and "TLS 1.3".

top
UncommonOptions
Declare.s ckUncommonOptions(obj.i)
Declare setCkUncommonOptions(obj.i, value.s)
Introduced in version 9.5.0.80

This is a catch-all property to be used for uncommon needs. This property defaults to the empty string and should typically remain empty. Can be set to a list of the following comma separated keywords:

  • "ProtectFromVpn" - Introduced in v9.5.0.80. On Android systems, will bypass any VPN that may be installed or active.
  • "EnableTls13" - Introduced in v9.5.0.82. Causes TLS 1.3 to be offered in the ClientHello of the TLS protocol, allowing the server to select TLS 1.3 for the session. Future versions of Chilkat will enable TLS 1.3 by default. This option is only necessary in v9.5.0.82 if TLS 1.3 is desired.

More Information and Examples
top
UserData
Declare.s ckUserData(obj.i)
Declare setCkUserData(obj.i, value.s)

Provides a way to store text data with the socket object. The UserData is purely for convenience and is not involved in the socket communications in any way. An application might use this property to keep extra information associated with the socket.

top
VerboseLogging
Declare.i ckVerboseLogging(obj.i)
Declare setCkVerboseLogging(obj.i, value.i)

If set to 1, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is 0. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top
Version
Declare.s ckVersion(obj.i) ; (read-only)

Version of the component/library, such as "9.5.0.94"

More Information and Examples
top

Methods

AcceptNextConnection
Declare.i ckAcceptNextConnection(obj.i, maxWaitMs.l)

Blocking call to accept the next incoming connection on the socket. maxWaitMs specifies the maximum time to wait (in milliseconds). Set this to 0 to wait indefinitely. If successful, a new socket object is returned.

Important: If accepting an SSL/TLS connection, the SSL handshake is part of the connection establishment process. This involves a few back-and-forth messages between the client and server to establish algorithms and a shared key to create the secure channel. The sending and receiving of these messages are governed by the MaxReadIdleMs and MaxSendIdleMs properties. If these properties are set to 0 (and this is the default unless changed by your application), then the AcceptNextConnection can hang indefinitely during the SSL handshake process. Make sure these properties are set to appropriate values before calling this method.

Returns 0 on failure

top
AcceptNextConnectionAsync (1) (2)
Declare.i ckAcceptNextConnectionAsync(obj.i, maxWaitMs.l)

Creates an asynchronous task to call the AcceptNextConnection method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
AddSslAcceptableClientCaDn
Declare.i ckAddSslAcceptableClientCaDn(obj.i, certAuthDN.s)

If this object is a server-side socket accepting SSL/TLS connections, and wishes to require a client-side certificate for authentication, then it should make one or more calls to this method to identify the CA's it will accept for client-side certificates.

If no CA DN's are added by this method, then client certificates from any root CA are accepted.

Important: If calling this method, it must be called before calling InitSslServer.

Returns 1 for success, 0 for failure.

top
BindAndListen
Declare.i ckBindAndListen(obj.i, port.l, backLog.l)

Binds a TCP socket to a port and configures it to listen for incoming connections. The size of the backlog is passed in backLog. The backLog is necessary when multiple connections arrive at the same time, or close enough in time such that they cannot be serviced immediately. (A typical value to use for backLog is 5.) This method should be called once prior to receiving incoming connection requests via the AcceptNextConnection or AsyncAcceptStart methods.

Note:This method will find a random unused port to listen on if you bind to port 0. The chosen port is available via the read-only ListenPort property after this method returns successful.

To bind and listen using IPv6, set the ListenIpv6 property = 1 prior to calling this method.

What is a reasonable value for backLog? The answer depends on how many simultaneous incoming connections could be expected, and how quickly your application can process an incoming connection and then return to accept the next connection.

Returns 1 for success, 0 for failure.

top
BindAndListenAsync (1)
Declare.i ckBindAndListenAsync(obj.i, port.l, backLog.l)

Creates an asynchronous task to call the BindAndListen method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
BindAndListenPortRange
Declare.i ckBindAndListenPortRange(obj.i, beginPort.l, endPort.l, backLog.l)
Introduced in version 9.5.0.69

Binds a TCP socket to an unused port within a port range (beginPort to endPort) and configures it to listen for incoming connections. The size of the backlog is passed in backLog. The backLog is necessary when multiple connections arrive at the same time, or close enough in time such that they cannot be serviced immediately. (A typical value to use for backLog is 5.) This method should be called once prior to receiving incoming connection requests via the AcceptNextConnection method.

To bind and listen using IPv6, set the ListenIpv6 property = 1 prior to calling this method.

Returns the port number that was bound, or -1 if no port was available or if it failed for some other reason.

top
BindAndListenPortRangeAsync (1)
Declare.i ckBindAndListenPortRangeAsync(obj.i, beginPort.l, endPort.l, backLog.l)
Introduced in version 9.5.0.69

Creates an asynchronous task to call the BindAndListenPortRange method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
BuildHttpGetRequest
Declare.s ckBuildHttpGetRequest(obj.i, url.s)
Introduced in version 9.5.0.35

Convenience method for building a simple HTTP GET request from a URL.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

More Information and Examples
top
CheckWriteable
Declare.i ckCheckWriteable(obj.i, maxWaitMs.l)

Determines if the socket is writeable. Returns one of the following integer values:

1: If the socket is connected and ready for writing.
0: If a timeout occurred or if the application aborted the method during an event callback.
-1: The socket is not connected.

A maxWaitMs value of 0 indicates a poll.

top
CheckWriteableAsync (1)
Declare.i ckCheckWriteableAsync(obj.i, maxWaitMs.l)

Creates an asynchronous task to call the CheckWriteable method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ClearSessionLog
Declare ckClearSessionLog(obj.i)

Clears the contents of the SessionLog property.

top
CloneSocket
Declare.i ckCloneSocket(obj.i)
Introduced in version 9.5.0.47

Creates a copy that shares the same underlying TCP (or SSL/TLS) connection. This allows for simultaneous reading/writing by different threads on the socket. When using asynchronous reading/writing, it is not necessary to clone the socket. However, if separate background threads are making synchronous calls to read/write, then one thread may use the original socket, and the other should use a clone.

Returns 0 on failure

top
Close
Declare.i ckClose(obj.i, maxWaitMs.l)

Cleanly terminates and closes a TCP, TLS, or SSH channel connection.

Returns 1 for success, 0 for failure.

top
CloseAsync (1)
Declare.i ckCloseAsync(obj.i, maxWaitMs.l)

Creates an asynchronous task to call the Close method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
Connect
Declare.i ckConnect(obj.i, hostname.s, port.l, ssl.l, maxWaitMs.l)

Establishes a secure SSL/TLS or a plain non-secure TCP connection with a remote host:port. This is a blocking call. The maximum wait time (in milliseconds) is passed in maxWaitMs. This is the amount of time the app is willing to wait for the TCP connection to be accepted (see additional notes below).

The hostname can be a domain name (i.e. example.com), an IPv4 dotted address string such as "3.101.18.47", or an IPv6 address string such as "2345:0425:2CA1:0000:0000:0567:5673:23b5", or "2345:0425:2CA1::0567:5673:23b5", etc.

To establish an SSL/TLS connection, set ssl = 1, otherwise set ssl = 0 for a normal TCP connection. Note: The timeouts that apply to the internal SSL/TLS handshaking messages are the MaxReadIdleMs and MaxSendIdleMs properties.

Note: The maxWaitMs only applies to the actual TCP connect, i.e. the max time to wait for the TCP connect to be accepted. The MaxReadIdleMs property applies to DNS (if hostname is a domain name), to any SOCKS or HTTP proxy communications, and to SSL/TLS handshake communications.

Note: Connections do not automatically close because of inactivity. A connection will remain open indefinitely even if there is no activity.

Important: All TCP-based Internet communications, regardless of the protocol (such as HTTP, FTP, SSH, IMAP, POP3, SMTP, etc.), and regardless of SSL/TLS, begin with establishing a TCP connection to a remote host:port. External security-related infrastructure such as software firewalls (Windows Firewall), hardware firewalls, anti-virus, at either source or destination (or both) can block the connection. If the connection fails, make sure to check all potential external causes of blockage.

Question: How do I Choose the TLS version, such as 1.2? Answer: The client does not specifically choose the TLS version. In the TLS handshake (which is what occurs internally in this method), the client tells the server the version of the TLS protocol it wishes to use, which should be the highest version is supports. In this case, (at the time of this writing on 22-June-2017) it is TLS 1.2. The server then chooses the TLS version that will actually be used. In most cases it will be TLS 1.2. The client can then choose to accept or reject the connection based on the TLS version chosen by the server. By default, Chilkat will reject anything lower than SSL 3.0 (i.e. SSL 2.0 or lower is rejected). The SslProtocol property can be set to change what is accepted by Chilkat. For example, it can be set to "TLS 1.0 or higher".

Returns 1 for success, 0 for failure.

top
ConnectAsync (1)
Declare.i ckConnectAsync(obj.i, hostname.s, port.l, ssl.l, maxWaitMs.l)

Creates an asynchronous task to call the Connect method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

More Information and Examples
top
ConvertFromSsl
Declare.i ckConvertFromSsl(obj.i)

Closes the secure (TLS/SSL) channel leaving the socket in a connected state where data sent and received is unencrypted.

Returns 1 for success, 0 for failure.

top
ConvertFromSslAsync (1)
Declare.i ckConvertFromSslAsync(obj.i)

Creates an asynchronous task to call the ConvertFromSsl method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ConvertToSsl
Declare.i ckConvertToSsl(obj.i)

Converts a non-SSL/TLS connected socket to a secure channel using TLS/SSL.

Returns 1 for success, 0 for failure.

top
ConvertToSslAsync (1)
Declare.i ckConvertToSslAsync(obj.i)

Creates an asynchronous task to call the ConvertToSsl method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
DnsCacheClear
Declare ckDnsCacheClear(obj.i)
Introduced in version 9.5.0.38

Clears the Chilkat-wide in-memory hostname-to-IP address DNS cache. Chilkat automatically maintains this in-memory cache to prevent redundant DNS lookups. If the TTL on the DNS A records being accessed are short and/or these DNS records change frequently, then this method can be called clear the internal cache. Note: The DNS cache is used/shared among all Chilkat objects in a program, and clearing the cache affects all Chilkat objects.

top
DnsLookup
Declare.s ckDnsLookup(obj.i, hostname.s, maxWaitMs.l)

Performs a DNS query to resolve a hostname to an IP address. The IP address is returned if successful. The maximum time to wait (in milliseconds) is passed in maxWaitMs. To wait indefinitely, set maxWaitMs = 0.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

More Information and Examples
top
DnsLookupAsync (1)
Declare.i ckDnsLookupAsync(obj.i, hostname.s, maxWaitMs.l)

Creates an asynchronous task to call the DnsLookup method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
GetMyCert
Declare.i ckGetMyCert(obj.i)

Returns the digital certificate to be used for SSL connections. This method would only be called by an SSL server application. The SSL certificate is initially specified by calling InitSslServer.

Returns 0 on failure

top
GetReceivedClientCert
Declare.i ckGetReceivedClientCert(obj.i, index.l)

Returns the Nth client certificate received during an SSL/TLS handshake. This method only applies to the server-side of an SSL/TLS connection. The 1st client certificate is at index 0. The NumReceivedClientCerts property indicates the number of client certificates received during the SSL/TLS connection establishment.

Client certificates are customarily only sent when the server demands client-side authentication, as in 2-way SSL/TLS. This method provides the ability for the server to access and examine the client-side certs immediately after a connection is established. (Of course, if the client-side certs are inadequate for authentication, then the application can choose to immediately disconnect.)

Important: This method should be called from the socket object that is returned by AcceptNextConnection.

Returns 0 on failure

top
GetSslAcceptableClientCaDn
Declare.s ckGetSslAcceptableClientCaDn(obj.i, index.l)

If connected as an SSL/TLS client to an SSL/TLS server where the server requires a client-side certificate for authentication, then the NumSslAcceptableClientCAs property contains the number of acceptable certificate authorities sent by the server during connection establishment handshake. This method may be called to get the Distinguished Name (DN) of each acceptable CA. The index should range from 0 to NumSslAcceptableClientCAs - 1.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
GetSslServerCert
Declare.i ckGetSslServerCert(obj.i)

Returns the SSL server's digital certificate. This method would only be called by the client-side of an SSL connection. It returns the certificate of the remote SSL server for the current SSL connection. If the socket is not connected, or is not connected via SSL, then a NULL reference is returned.

Returns 0 on failure

More Information and Examples
top
InitSslServer
Declare.i ckInitSslServer(obj.i, cert.i)

SSL/TLS Server applications should call this method with the SSL server certificate to be used for SSL/TLS connections. It should be called prior to accepting connections. This method has an intended side-effect: If not already connected, then the Ssl property is set to 1.

Returns 1 for success, 0 for failure.

More Information and Examples
top
LastJsonData
Declare.i ckLastJsonData(obj.i)
Introduced in version 9.5.0.79

Provides information about what transpired in the last method called on this object instance. For many methods, there is no information. However, for some methods, details about what occurred can be obtained by getting the LastJsonData right after the method call returns.

Returns 0 on failure

top
LoadTaskCaller
Declare.i ckLoadTaskCaller(obj.i, task.i)
Introduced in version 9.5.0.80

Loads the caller of the task's async method.

Returns 1 for success, 0 for failure.

top
LoadTaskResult
Declare.i ckLoadTaskResult(obj.i, task.i)
Introduced in version 9.5.0.52

Loads the socket object from a completed asynchronous task.

Returns 1 for success, 0 for failure.

top
PollDataAvailable
Declare.i ckPollDataAvailable(obj.i)

Check to see if data is available for reading on the socket. Returns 1 if data is waiting and 0 if no data is waiting to be read.

top
PollDataAvailableAsync (1)
Declare.i ckPollDataAvailableAsync(obj.i)

Creates an asynchronous task to call the PollDataAvailable method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveBd
Declare.i ckReceiveBd(obj.i, binData.i)
Introduced in version 9.5.0.65

Receives as much data as is immediately available on a connected TCP socket and appends the incoming data to binData. If no data is immediately available, it waits up to MaxReadIdleMs milliseconds for data to arrive.

Returns 1 for success, 0 for failure.

top
ReceiveBdAsync (1)
Declare.i ckReceiveBdAsync(obj.i, binData.i)
Introduced in version 9.5.0.65

Creates an asynchronous task to call the ReceiveBd method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveBdN
Declare.i ckReceiveBdN(obj.i, numBytes.l, binData.i)
Introduced in version 9.5.0.65

Reads exactly numBytes bytes from the connection. This method blocks until numBytes bytes are read or the read times out. The timeout is specified by the MaxReadIdleMs property (in milliseconds).

Returns 1 for success, 0 for failure.

More Information and Examples
top
ReceiveBdNAsync (1)
Declare.i ckReceiveBdNAsync(obj.i, numBytes.l, binData.i)
Introduced in version 9.5.0.65

Creates an asynchronous task to call the ReceiveBdN method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveByte
Declare.i ckReceiveByte(obj.i, bUnsigned.l)
Introduced in version 9.5.0.50

Receives a single byte. The received byte will be available in the ReceivedInt property. If bUnsigned is 1, then a value from 0 to 255 is returned in ReceivedInt. If bUnsigned is 0, then a value from -128 to +127 is returned.

Returns 1 for success, 0 for failure.

More Information and Examples
top
ReceiveByteAsync (1)
Declare.i ckReceiveByteAsync(obj.i, bUnsigned.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the ReceiveByte method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveBytesENC
Declare.s ckReceiveBytesENC(obj.i, encodingAlg.s)

The same as ReceiveBytes, except the bytes are returned in encoded string form according to encodingAlg. The encodingAlg can be "Base64", "modBase64", "Base32", "UU", "QP" (for quoted-printable), "URL" (for url-encoding), "Hex", "Q", "B", "url_oath", "url_rfc1738", "url_rfc2396", or "url_rfc3986".

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveBytesENCAsync (1)
Declare.i ckReceiveBytesENCAsync(obj.i, encodingAlg.s)

Creates an asynchronous task to call the ReceiveBytesENC method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveBytesToFile
Declare.i ckReceiveBytesToFile(obj.i, appendFilename.s)

Receives as much data as is immediately available on a connected TCP socket. If no data is immediately available, it waits up to MaxReadIdleMs milliseconds for data to arrive.

The received data is appended to the file specified by appendFilename.

Returns 1 for success, 0 for failure.

top
ReceiveBytesToFileAsync (1)
Declare.i ckReceiveBytesToFileAsync(obj.i, appendFilename.s)

Creates an asynchronous task to call the ReceiveBytesToFile method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveCount
Declare.i ckReceiveCount(obj.i)

Receives a 4-byte signed integer and returns the value received. Returns -1 on error.

top
ReceiveCountAsync (1)
Declare.i ckReceiveCountAsync(obj.i)

Creates an asynchronous task to call the ReceiveCount method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveInt16
Declare.i ckReceiveInt16(obj.i, bigEndian.l, bUnsigned.l)
Introduced in version 9.5.0.50

Receives a 16-bit integer (2 bytes). The received integer will be available in the ReceivedInt property. Set bigEndian equal to 1 if the incoming 16-bit integer is in big-endian byte order. Otherwise set bigEndian equal to 0 for receving a little-endian integer. If bUnsigned is 1, the ReceivedInt will range from 0 to 65,535. If bUnsigned is 0, the ReceivedInt will range from -32,768 through 32,767.

Returns 1 for success, 0 for failure.

More Information and Examples
top
ReceiveInt16Async (1)
Declare.i ckReceiveInt16Async(obj.i, bigEndian.l, bUnsigned.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the ReceiveInt16 method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveInt32
Declare.i ckReceiveInt32(obj.i, bigEndian.l)
Introduced in version 9.5.0.50

Receives a 32-bit integer (4 bytes). The received integer will be available in the ReceivedInt property. Set bigEndian equal to 1 if the incoming 32-bit integer is in big-endian byte order. Otherwise set bigEndian equal to 0 for receving a little-endian integer.

Returns 1 for success, 0 for failure.

top
ReceiveInt32Async (1)
Declare.i ckReceiveInt32Async(obj.i, bigEndian.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the ReceiveInt32 method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveNBytesENC
Declare.s ckReceiveNBytesENC(obj.i, numBytes.l, encodingAlg.s)

The same as ReceiveBytesN, except the bytes are returned in encoded string form using the encoding specified by numBytes. The numBytes can be "Base64", "modBase64", "Base32", "UU", "QP" (for quoted-printable), "URL" (for url-encoding), "Hex", "Q", "B", "url_oath", "url_rfc1738", "url_rfc2396", or "url_rfc3986".

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveNBytesENCAsync (1)
Declare.i ckReceiveNBytesENCAsync(obj.i, numBytes.l, encodingAlg.s)

Creates an asynchronous task to call the ReceiveNBytesENC method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveSb
Declare.i ckReceiveSb(obj.i, sb.i)
Introduced in version 9.5.0.65

Receives as much data as is immediately available on the connection. If no data is immediately available, it waits up to MaxReadIdleMs milliseconds for data to arrive. The incoming bytes are interpreted according to the StringCharset property and appended to sb.

Returns 1 for success, 0 for failure.

top
ReceiveSbAsync (1)
Declare.i ckReceiveSbAsync(obj.i, sb.i)
Introduced in version 9.5.0.65

Creates an asynchronous task to call the ReceiveSb method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveString
Declare.s ckReceiveString(obj.i)

Receives as much data as is immediately available on a TCP/IP or SSL socket. If no data is immediately available, it waits up to MaxReadIdleMs milliseconds for data to arrive. The incoming bytes are interpreted according to the StringCharset property and returned as a string.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveStringAsync (1)
Declare.i ckReceiveStringAsync(obj.i)

Creates an asynchronous task to call the ReceiveString method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveStringMaxN
Declare.s ckReceiveStringMaxN(obj.i, maxByteCount.l)

Same as ReceiveString, but limits the amount of data returned to a maximum of maxByteCount bytes.

(Receives as much data as is immediately available on the TCP/IP or SSL socket. If no data is immediately available, it waits up to MaxReadIdleMs milliseconds for data to arrive. The incoming bytes are interpreted according to the StringCharset property and returned as a string.)

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveStringMaxNAsync (1)
Declare.i ckReceiveStringMaxNAsync(obj.i, maxByteCount.l)

Creates an asynchronous task to call the ReceiveStringMaxN method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveStringUntilByte
Declare.s ckReceiveStringUntilByte(obj.i, lookForByte.l)

Receives bytes on a connected SSL or non-SSL socket until a specific 1-byte value is read. Returns a string containing all the bytes up to but excluding the lookForByte.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveStringUntilByteAsync (1)
Declare.i ckReceiveStringUntilByteAsync(obj.i, lookForByte.l)

Creates an asynchronous task to call the ReceiveStringUntilByte method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveToCRLF
Declare.s ckReceiveToCRLF(obj.i)

Reads text from the connected TCP/IP or SSL socket until a CRLF is received. Returns the text up to and including the CRLF. The incoming bytes are interpreted according to the charset specified by the StringCharset property.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveToCRLFAsync (1)
Declare.i ckReceiveToCRLFAsync(obj.i)

Creates an asynchronous task to call the ReceiveToCRLF method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveUntilByteBd
Declare.i ckReceiveUntilByteBd(obj.i, lookForByte.l, bd.i)
Introduced in version 9.5.0.76

Receives bytes on the TCP/IP or SSL socket until a specific 1-byte value is read. Returns all the bytes up to and including the lookForByte. The received bytes are appended to bd.

Returns 1 for success, 0 for failure.

top
ReceiveUntilByteBdAsync (1)
Declare.i ckReceiveUntilByteBdAsync(obj.i, lookForByte.l, bd.i)
Introduced in version 9.5.0.76

Creates an asynchronous task to call the ReceiveUntilByteBd method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
ReceiveUntilMatch
Declare.s ckReceiveUntilMatch(obj.i, matchStr.s)

Reads text from the connected TCP/IP or SSL socket until a matching string (matchStr) is received. Returns the text up to and including the matching string. As an example, to one might read the header of an HTTP request or a MIME message by reading up to the first double CRLF ("\r\n\r\n"). The incoming bytes are interpreted according to the charset specified by the StringCharset property.

Remember: All Receive* methods will stop trying to receive if incoming data stops arriving for more than the number of milliseconds indicated by the MaxReadIdleMs property. If this happens, the method return value indicates failure and the ReceiveFailReason property would have the value 5 (for Timeout).

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
ReceiveUntilMatchAsync (1)
Declare.i ckReceiveUntilMatchAsync(obj.i, matchStr.s)

Creates an asynchronous task to call the ReceiveUntilMatch method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

More Information and Examples
top
ResetPerf
Declare ckResetPerf(obj.i, rcvPerf.l)
Introduced in version 9.5.0.78

Resets the performance measurements for either receiving or sending. If rcvPerf is 1, then the receive performance monitoring is reset. If rcvPerf is 0, then the sending performance monitoring is reset.

top
SelectForReading
Declare.i ckSelectForReading(obj.i, timeoutMs.l)

Wait for data to arrive on this socket, or any of the contained sockets if the caller is a "socket set". (If the socket is a listener socket, then waits for an incoming connect. Listener sockets can be added to the "socket set" just like connected sockets.)

(see the example at the link below for more detailed information)

Waits a maximum of timeoutMs milliseconds. If maxWaitMs = 0, then it is effectively a poll. Returns the number of sockets with data available for reading. If no sockets have data available for reading, then a value of 0 is returned. A value of -1 indicates an error condition. Note: when the remote peer (in this case the web server) disconnects, the socket will appear as if it has data available. A "ready" socket is one where either data is available for reading or the socket has become disconnected.

If the peer closed the connection, it will not be discovered until an attempt is made to read the socket. If the read fails, then the IsConnected property may be checked to see if the connection was closed.

More Information and Examples
top
SelectForReadingAsync (1)
Declare.i ckSelectForReadingAsync(obj.i, timeoutMs.l)

Creates an asynchronous task to call the SelectForReading method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SelectForWriting
Declare.i ckSelectForWriting(obj.i, timeoutMs.l)

Waits until it is known that data can be written to one or more sockets without it blocking.

Socket writes are typically buffered by the operating system. When an application writes data to a socket, the operating system appends it to the socket's outgoing send buffers and returns immediately. However, if the OS send buffers become filled up (because the sender is sending data faster than the remote receiver can read it), then a socket write can block (until outgoing send buffer space becomes available).

Waits a maximum of timeoutMs milliseconds. If maxWaitMs = 0, then it is effectively a poll. Returns the number of sockets such that data can be written without blocking. A value of -1 indicates an error condition.

top
SelectForWritingAsync (1)
Declare.i ckSelectForWritingAsync(obj.i, timeoutMs.l)

Creates an asynchronous task to call the SelectForWriting method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendBd
Declare.i ckSendBd(obj.i, binData.i, offset.l, numBytes.l)
Introduced in version 9.5.0.65

Sends bytes from binData over a connected SSL or non-SSL socket. If transmission halts for more than MaxSendIdleMs milliseconds, the send is aborted. This is a blocking (synchronous) method. It returns only after the bytes have been sent.

Set offset and/or numBytes to non-zero values to send a portion of the binData. If offset and numBytes are both 0, then the entire binData is sent. If offset is non-zero and numBytes is zero, then the bytes starting at offset until the end are sent.

Returns 1 for success, 0 for failure.

top
SendBdAsync (1)
Declare.i ckSendBdAsync(obj.i, binData.i, offset.l, numBytes.l)
Introduced in version 9.5.0.65

Creates an asynchronous task to call the SendBd method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendByte
Declare.i ckSendByte(obj.i, value.l)
Introduced in version 9.5.0.50

Sends a single byte. The integer must have a value from 0 to 255.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SendByteAsync (1)
Declare.i ckSendByteAsync(obj.i, value.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SendByte method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendBytesENC
Declare.i ckSendBytesENC(obj.i, encodedBytes.s, encodingAlg.s)

The same as SendBytes, except the bytes are provided in encoded string form as specified by encodingAlg. The encodingAlg can be "Base64", "modBase64", "Base32", "Base58", "UU", "QP" (for quoted-printable), "URL" (for url-encoding), "Hex", "Q", "B", "url_oauth", "url_rfc1738", "url_rfc2396", and "url_rfc3986".

For example, you can call this method with the following arguments: "00010203040506","hex" to send 7 binary bytes with values 00, 01, 02, 03, 04, 05, 06.

top
SendBytesENCAsync (1)
Declare.i ckSendBytesENCAsync(obj.i, encodedBytes.s, encodingAlg.s)

Creates an asynchronous task to call the SendBytesENC method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendCount
Declare.i ckSendCount(obj.i, byteCount.l)

Sends a 4-byte signed integer on the connection. The receiver may call ReceiveCount to receive the integer. The SendCount and ReceiveCount methods are handy for sending byte counts prior to sending data. The sender would send a count followed by the data, and the receiver would receive the count first, and then knows how many data bytes it should expect to receive.

Returns 1 for success, 0 for failure.

top
SendCountAsync (1)
Declare.i ckSendCountAsync(obj.i, byteCount.l)

Creates an asynchronous task to call the SendCount method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendInt16
Declare.i ckSendInt16(obj.i, value.l, bigEndian.l)
Introduced in version 9.5.0.50

Sends a 16-bit integer (2 bytes). Set bigEndian equal to 1 to send the integer in big-endian byte order (this is the standard network byte order). Otherwise set bigEndian equal to 0 to send in little-endian byte order.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SendInt16Async (1)
Declare.i ckSendInt16Async(obj.i, value.l, bigEndian.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SendInt16 method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendInt32
Declare.i ckSendInt32(obj.i, value.l, bigEndian.l)
Introduced in version 9.5.0.50

Sends a 32-bit integer (4 bytes). Set bigEndian equal to 1 to send the integer in big-endian byte order (this is the standard network byte order). Otherwise set bigEndian equal to 0 to send in little-endian byte order.

Returns 1 for success, 0 for failure.

top
SendInt32Async (1)
Declare.i ckSendInt32Async(obj.i, value.l, bigEndian.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SendInt32 method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendSb
Declare.i ckSendSb(obj.i, sb.i)
Introduced in version 9.5.0.65

Sends the contents of sb over the connection. If transmission halts for more than MaxSendIdleMs milliseconds, the send is aborted. The string is sent in the charset encoding specified by the StringCharset property.

This is a blocking (synchronous) method. It returns after the string has been sent.

Returns 1 for success, 0 for failure.

top
SendSbAsync (1)
Declare.i ckSendSbAsync(obj.i, sb.i)
Introduced in version 9.5.0.65

Creates an asynchronous task to call the SendSb method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SendString
Declare.i ckSendString(obj.i, stringToSend.s)

Sends a string over a connected SSL or non-SSL (TCP/IP) socket. If transmission halts for more than MaxSendIdleMs milliseconds, the send is aborted. The string is sent in the charset encoding specified by the StringCharset property.

This is a blocking (synchronous) method. It returns after the string has been sent.

Returns 1 for success, 0 for failure.

top
SendStringAsync (1)
Declare.i ckSendStringAsync(obj.i, stringToSend.s)

Creates an asynchronous task to call the SendString method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

More Information and Examples
top
SendWakeOnLan
Declare.i ckSendWakeOnLan(obj.i, macAddress.s, port.l, ipBroadcastAddr.s)
Introduced in version 9.5.0.69

Sends a "Wake on Lan" magic packet to a computer. A Wake on Lan is a way to power on a computer remotely by sending a data packet known as a magic packet. For this to work, the network card must have enabled the feature: “Power on Lan” or “Power on PCI Device“, which is done by accessing the BIOS of the machine.

The macAddress is the MAC address (in hex) of the computer to wake. A MAC address should be 6 bytes in length. For example, "000102030405". The port is the port which should be 7 or 9. (Port number 9 is more commonly used.) The ipBroadcastAddr is the broadcast address of your network, which usually ends with *.255. For example: "192.168.1.255".

Your application does not call Connect prior to calling SendWakeOnLan. To use this method, it's just a matter of instantiating an instance of this socket object and then call SendWakeOnLan.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SendWakeOnLan2
Declare.i ckSendWakeOnLan2(obj.i, macAddress.s, port.l, ipBroadcastAddr.s, password.s)
Introduced in version 9.5.0.77

The same as SendWakeOnLan, but includes an additional argument to specify a SecureOn password. The password should be a hexidecimal string representing 4 or 6 bytes. (See https://wiki.wireshark.org/WakeOnLAN) Sending a WakeOnLAN (WOL) to an IPv4 address would need a 4-byte SecureOn password, whereas an IPv6 address would need a 6-byte SecureOn password.

Returns 1 for success, 0 for failure.

top
SetSslClientCert
Declare.i ckSetSslClientCert(obj.i, cert.i)

A client-side certificate for SSL/TLS connections is optional. It should be used only if the server demands it. This method allows the certificate to be specified using a certificate object.

Returns 1 for success, 0 for failure.

top
SetSslClientCertPem
Declare.i ckSetSslClientCertPem(obj.i, pemDataOrFilename.s, pemPassword.s)

A client-side certificate for SSL/TLS connections is optional. It should be used only if the server demands it. This method allows the certificate to be specified using a PEM file.

Returns 1 for success, 0 for failure.

top
SetSslClientCertPfx
Declare.i ckSetSslClientCertPfx(obj.i, pfxFilename.s, pfxPassword.s)

A client-side certificate for SSL/TLS connections is optional. It should be used only if the server demands it. This method allows the certificate to be specified using a PFX file.

Returns 1 for success, 0 for failure.

top
SleepMs
Declare ckSleepMs(obj.i, millisec.l)

Convenience method to force the calling thread to sleep for a number of milliseconds.

top
SshAuthenticatePk
Declare.i ckSshAuthenticatePk(obj.i, sshLogin.s, privateKey.i)
Introduced in version 9.5.0.50

Authenticates with the SSH server using public-key authentication. The corresponding public key must have been installed on the SSH server for the sshLogin. Authentication will succeed if the matching privateKey is provided.

Important: When reporting problems, please send the full contents of the LastErrorText property to support@chilkatsoft.com.

Returns 1 for success, 0 for failure.

top
SshAuthenticatePkAsync (1)
Declare.i ckSshAuthenticatePkAsync(obj.i, sshLogin.s, privateKey.i)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SshAuthenticatePk method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SshAuthenticatePw
Declare.i ckSshAuthenticatePw(obj.i, sshLogin.s, sshPassword.s)
Introduced in version 9.5.0.50

Authenticates with the SSH server using a sshLogin and sshPassword. This method is only used for SSH tunneling. The tunnel is established by calling SshOpenTunnel, then (if necessary) authenticated by calling SshAuthenticatePw or SshAuthenticatePk.

Returns 1 for success, 0 for failure.

top
SshAuthenticatePwAsync (1)
Declare.i ckSshAuthenticatePwAsync(obj.i, sshLogin.s, sshPassword.s)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SshAuthenticatePw method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SshCloseTunnel
Declare.i ckSshCloseTunnel(obj.i)
Introduced in version 9.5.0.50

Closes the SSH tunnel previously opened by SshOpenTunnel.

Returns 1 for success, 0 for failure.

top
SshCloseTunnelAsync (1)
Declare.i ckSshCloseTunnelAsync(obj.i)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SshCloseTunnel method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SshOpenChannel
Declare.i ckSshOpenChannel(obj.i, hostname.s, port.l, ssl.l, maxWaitMs.l)
Introduced in version 9.5.0.50

Opens a new channel within an SSH tunnel. Returns the socket that is connected to the destination host:port through the SSH tunnel via port forwarding. If ssl is 1, the connection is TLS (i.e. TLS inside the SSH tunnel). Returns the socket object that is the port-forwarded tunneled connection. Any number of channels may be opened within a single SSH tunnel, and may be port-forwarded to different remote host:port endpoints.

Returns 0 on failure

top
SshOpenChannelAsync (1) (2)
Declare.i ckSshOpenChannelAsync(obj.i, hostname.s, port.l, ssl.l, maxWaitMs.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SshOpenChannel method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SshOpenTunnel
Declare.i ckSshOpenTunnel(obj.i, sshHostname.s, sshPort.l)
Introduced in version 9.5.0.50

Connects to an SSH server and creates a tunnel for port forwarding. The sshHostname is the hostname (or IP address) of the SSH server. The sshPort is typically 22, which is the standard SSH port number.

An SSH tunneling (port forwarding) session always begins by first calling SshOpenTunnel to connect to the SSH server, followed by calling either SshAuthenticatePw or SshAuthenticatePk to authenticate. A program would then call SshOpenChannel to connect to the destination server (via the SSH tunnel). Any number of channels can be opened over the same SSH tunnel.

The MaxReadIdleMs property applies to this method for controlling how long it takes before a timeout.

Returns 1 for success, 0 for failure.

top
SshOpenTunnelAsync (1)
Declare.i ckSshOpenTunnelAsync(obj.i, sshHostname.s, sshPort.l)
Introduced in version 9.5.0.50

Creates an asynchronous task to call the SshOpenTunnel method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
StartTiming
Declare ckStartTiming(obj.i)

Used in combination with the ElapsedSeconds property, which will contain the number of seconds since the last call to this method. (The StartTiming method and ElapsedSeconds property is provided for convenience.)

top
TakeConnection
Declare.i ckTakeConnection(obj.i, sock.i)
Introduced in version 9.5.0.77

Takes the connection from sock. If the caller of this method had an open connection, then it will be closed. This method is different than the TakeSocket method because the caller does not become a "socket set".

Returns 1 for success, 0 for failure.

top
TakeSocket
Declare.i ckTakeSocket(obj.i, sock.i)

Takes ownership of the sock. sock is added to the internal set of connected sockets. The caller object is now effectively a "socket set", i.e. a collection of connected and/or listener sockets. Method calls are routed to the internal sockets based on the value of the SelectorIndex property. For example, if SelectorIndex equals 2, then a call to SendBytes is actually a call to SendBytes on the 3rd socket in the set. (Indexing begins at 0.) Likewise, getting and setting properties are also routed to the contained socket based on SelectorIndex. It is possible to wait on a set of sockets for data to arrive on any of them by calling SelectForReading. See the example link below.

Returns 1 for success, 0 for failure.

More Information and Examples
top
TlsRenegotiate
Declare.i ckTlsRenegotiate(obj.i)
Introduced in version 9.5.0.55

Initiates a renegotiation of the TLS security parameters. This sends a ClientHello to re-do the TLS handshake to establish new TLS security params.

Returns 1 for success, 0 for failure.

top
TlsRenegotiateAsync (1)
Declare.i ckTlsRenegotiateAsync(obj.i)
Introduced in version 9.5.0.55

Creates an asynchronous task to call the TlsRenegotiate method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
UseSsh
Declare.i ckUseSsh(obj.i, ssh.i)
Introduced in version 9.5.0.55

Uses an existing SSH tunnel for the connection. This is an alternative way of establishing a socket connection through an SSH tunnel. There are four ways of running a TCP or SSL/TLS connection through an SSH tunnel:

  1. UseSsh
    1. Establish the SSH connection and authenticate using the Chilkat SSH object.
    2. Call UseSsh to indicate that the connections should be made through the SSH tunnel.
    3. Call the Connect method to establish the TCP or SSL/TLS connection with a destination host:port. The connection is not direct, but will instead be routed through the SSH tunnel and then port-forwarded (from the SSH server) to the destination host:port. (Had UseSsh not been called, the connection would be direct.)
  2. SshOpenTunnel
    1. Call the Socket object's SshOpenTunnel method to connect to an SSH server.
    2. Call SshAuthenticatePw to authenticate with the SSH server.
    3. Instead of calling Connect to connect with the destination host:port, the SshOpenChannel method is called to connect via port-forwarding through the SSH tunnel.
  3. SshTunnel object with dynamic port forwarding
    1. The Chilkat SSH Tunnel object is utilized to run in a background thread. It connects and authenticates with an SSH server, and then listens at a port chosen by the application, and behaves as a SOCKS5 proxy server.
    2. The Socket object sets the SOCKS5 proxy host:port to localhost:<port>,
    3. The Socket's Connect method is called to connect via the SSH Tunnel. The connection is routed through the SSH tunnel via dynamic port forwarding.
    4. Once the background SSH Tunnel thread is running, it can handle any number of incoming connections from the foreground thread, other threads, or even other programs that are local or remote. Each incoming connection is routed via dynamic port forwarding to it's chosen destnation host:port on it's own logical SSH channel.
  4. SshTunnel object with hard-coded port forwarding
    1. The Chilkat SSH Tunnel object is utilized to run in a background thread. It connects and authenticates with an SSH server, and then listens at a port chosen by the application. It does not behave as a SOCKS5 proxy server, but instead has a hard-coded destination host:port.
    2. The Socket's Connect method is called to connect to localhost:<port>. The connection is automatically port-forwarded through the SSH tunnel to the hard-coded destination host:port.
In all cases, the SSH tunnels can hold both unencrypted TCP connections and SSL/TLS connections.

Returns 1 for success, 0 for failure.

top