connectToHost() is the most-used function. As its name implies, it opens a connection to a named host.
.PP
Most network protocols are either packet-oriented or line-oriented. canReadLine() indicates whether a connection contains an entire unread line or not, and bytesAvailable() returns the number of bytes available for reading.
.PP
The signals error(), connected(), readyRead() and connectionClosed() inform you of the progress of the connection. There are also some less commonly used signals. hostFound() is emitted when connectToHost() has finished its DNS lookup and is starting its TCP connection. delayedCloseFinished() is emitted when close() succeeds. bytesWritten() is emitted when QSocket moves data from its "to be written" queue into the TCP implementation.
.PP
There are several access functions for the socket: state() returns whether the object is idle, is doing a DNS lookup, is connecting, has an operational connection, etc. address() and port() return the IP address and port used for the connection. The peerAddress() and peerPort() functions return the IP address and port used by the peer, and peerName() returns the name of the peer (normally the name that was passed to connectToHost()). socketDevice() returns a pointer to the QSocketDevice used for this socket.
QSocket inherits TQIODevice, and reimplements some functions. In general, you can treat it as a TQIODevice for writing, and mostly also for reading. The match isn't perfect, since the TQIODevice API is designed for devices that are controlled by the same machine, and an asynchronous peer-to-peer network connection isn't quite like that. For example, there is nothing that matches TQIODevice::size() exactly. The documentation for open(), close(), flush(), size(), at(), atEnd(), readBlock(), writeBlock(), getch(), putch(), ungetch() and readLine() describes the differences in detail.
\fBWarning:\fR Because TQt doesn't use the native socketstream implementation on Mac OS X, QSocket has an implicit transfer latency of 100ms. You can achieve lower latency on Mac OS X by using QSocketDevice instead.
.SH "bool QSocket::at ( Offset index )\fC [virtual]\fR"
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Moves the read index forward to \fIindex\fR and returns TRUE if the operation was successful; otherwise returns FALSE. Moving the index forward means skipping incoming data.
Returns the number of bytes that are waiting to be written, i.e. the size of the output buffer.
.PP
See also bytesAvailable() and clearPendingData().
.SH "void QSocket::bytesWritten ( int nbytes )\fC [signal]\fR"
This signal is emitted when data has been written to the network. The \fInbytes\fR parameter specifies how many bytes were written.
.PP
The bytesToWrite() function is often used in the same context; it indicates how many buffered bytes there are left to write.
.PP
See also writeBlock() and bytesToWrite().
.SH "bool QSocket::canReadLine () const"
Returns TRUE if it's possible to read an entire line of text from this socket at this time; otherwise returns FALSE.
.PP
Note that if the peer closes the connection unexpectedly, this function returns FALSE. This means that loops such as this won't work:
.PP
.nf
.br
while( !socket->canReadLine() ) // WRONG
.br
;
.br
.fi
.PP
See also readLine().
.PP
Examples:
.)l network/clientserver/client/client.cpp, network/httpd/httpd.cpp, network/mail/smtp.cpp, and network/networkprotocol/nntp.cpp.
.SH "void QSocket::clearPendingData ()"
Deletes the data that is waiting to be written. This is useful if you want to close the socket without waiting for all the data to be written.
.PP
See also bytesToWrite(), close(), and delayedCloseFinished().
.SH "void QSocket::close ()\fC [virtual]\fR"
Closes the socket.
.PP
The read buffer is cleared.
.PP
If the output buffer is empty, the state is set to QSocket::Idle and the connection is terminated immediately. If the output buffer still contains data to be written, QSocket goes into the QSocket::Closing state and the rest of the data will be written. When all of the outgoing data have been written, the state is set to QSocket::Idle and the connection is terminated. At this point, the delayedCloseFinished() signal is emitted.
.PP
If you don't want that the data of the output buffer is written, call clearPendingData() before you call close().
.PP
See also state(), bytesToWrite(), and clearPendingData().
.PP
Examples:
.)l network/clientserver/client/client.cpp, network/httpd/httpd.cpp, and network/networkprotocol/nntp.cpp.
Attempts to make a connection to \fIhost\fR on the specified \fIport\fR and return immediately.
.PP
Any connection or pending connection is closed immediately, and QSocket goes into the HostLookup state. When the lookup succeeds, it emits hostFound(), starts a TCP connection and goes into the Connecting state. Finally, when the connection succeeds, it emits connected() and goes into the Connected state. If there is an error at any point, it emits error().
\fIhost\fR may be an IP address in string form, or it may be a DNS name. QSocket will do a normal DNS lookup if required. Note that \fIport\fR is in native byte order, unlike some other libraries.
This signal is emitted when the other end has closed the connection. The read buffers may contain buffered input data which you can read after the connection was closed.
.PP
See also connectToHost() and close().
.PP
Examples:
.)l network/clientserver/client/client.cpp, network/clientserver/server/server.cpp, and network/networkprotocol/nntp.cpp.
This signal is emitted when a delayed close is finished.
.PP
If you call close() and there is buffered output data to be written, QSocket goes into the QSocket::Closing state and returns immediately. It will then keep writing to the socket until all the data has been written. Then, the delayedCloseFinished() signal is emitted.
.PP
See also close().
.PP
Examples:
.)l network/clientserver/client/client.cpp and network/httpd/httpd.cpp.
.SH "void QSocket::error ( int )\fC [signal]\fR"
This signal is emitted after an error occurred. The parameter is the Error value.
.PP
Examples:
.)l network/clientserver/client/client.cpp and network/networkprotocol/nntp.cpp.
Opens the socket using the specified TQIODevice file mode \fIm\fR. This function is called automatically when needed and you should not call it yourself.
Returns a line of text including a terminating newline character (\\n). Returns "" if canReadLine() returns FALSE.
.PP
See also canReadLine().
.PP
Examples:
.)l network/clientserver/client/client.cpp, network/httpd/httpd.cpp, network/mail/smtp.cpp, and network/networkprotocol/nntp.cpp.
.SH "void QSocket::readyRead ()\fC [signal]\fR"
This signal is emitted every time there is new incoming data.
.PP
Bear in mind that new incoming data is only reported once; if you do not read all the data, this class buffers the data and you can read it later, but no signal is emitted unless new data arrives. A good practice is to read all data in the slot connected to this signal unless you are sure that you need to receive more data to be able to process it.
.PP
See also readBlock(), readLine(), and bytesAvailable().
.PP
Examples:
.)l network/clientserver/client/client.cpp, network/httpd/httpd.cpp, network/mail/smtp.cpp, and network/networkprotocol/nntp.cpp.
Sets the size of the QSocket's internal read buffer to \fIbufSize\fR.
.PP
Usually QSocket reads all data that is available from the operating system's socket. If the buffer size is limited to a certain size, this means that the QSocket class doesn't buffer more than this size of data.
.PP
If the size of the read buffer is 0, the read buffer is unlimited and all incoming data is buffered. This is the default.
.PP
If you read the data in the readyRead() signal, you shouldn't use this option since it might slow down your program unnecessary. This option is useful if you only need to read the data at certain points in time, like in a realtime streaming application.
.PP
See also readBufferSize().
.SH "void QSocket::setSocket ( int socket )\fC [virtual]\fR"
Sets the socket to use \fIsocket\fR and the state() to Connected. The socket must already be connected.
.PP
This allows us to use the QSocket class as a wrapper for other socket types (e.g. Unix Domain Sockets).
Sets the internal socket device to \fIdevice\fR. Passing a \fIdevice\fR of 0 will cause the internal socket device to be used. Any existing connection will be disconnected before using the new \fIdevice\fR.
.PP
The new device should not be connected before being associated with a QSocket; after setting the socket call connectToHost() to make the connection.
.PP
This function is useful if you need to subclass QSocketDevice and want to use the QSocket API, for example, to implement Unix domain sockets.
This implementation of the virtual function TQIODevice::ungetch() prepends the character \fIch\fR to the read buffer so that the next read returns this character as the first character of the output.
Wait up to \fImsecs\fR milliseconds for more data to be available.
.PP
If \fImsecs\fR is -1 the call will block indefinitely.
.PP
Returns the number of bytes available.
.PP
If \fItimeout\fR is non-null and no error occurred (i.e. it does not return -1): this function sets \fI*timeout\fR to TRUE, if the reason for returning was that the timeout was reached; otherwise it sets \fI*timeout\fR to FALSE. This is useful to find out if the peer closed the connection.
.PP
\fBWarning:\fR This is a blocking call and should be avoided in event driven applications.
