18 dec 2001 Status report
-----------------------------
I. VNC SESSION STABILITY
Now, the vnc session via Kaboodle is substantially more stable then it was
at the beginning. The main problem has been mostly solved.
1. Problem description.
There exists a very intensive data exchange between Vnc-viewer and
Vnc-listener. Vnc-listener sends the screen update info while Vnc-viewer
sends mouse movement info. Vnc-viewer uses the ClientConnection::ReadExact
function for data reading:
inline void ClientConnection::ReadExact(char *inbuf, int wanted)
{
int offset = 0;
//:
while (wanted > 0) {
int bytes = recv(m_sock, inbuf+offset, wanted, 0);
if (bytes == 0) throw WarningException("Connection closed.");
if (bytes == SOCKET_ERROR) {
// :
throw WarningException("ReadExact: Socket error while
reading.");
}
wanted -= bytes;
offset += bytes;
}
}
An example of simultaneous data exchange is when the user navigates through
a large-scale menu. Typically, a small data portion (e.g. mouse move info)
waits for a big portion (e.g. screen update info) to finish transmitting.
Here, SOCKET_ERROR often occurs and an exception is thrown.
As a result, we used to get a message box "ReadExact: Socket error while
reading" on the viewer side and the session was terminated.
2. The solution undertaken.
The methods of socket data read/write are now implemented the same way as in
VNC source:
- Sequential tries to receive the entire data portion until all the bytes
are read;
- A delay (Sleep function) between the tries.
For example, the function void CVncSessionDlg::ProcessKaboodleReceive()
contained the following line:
int iRcvd = m_KaboodleConnectionSocket.Receive( pReceiveTo, iAll);
Now it is substituted with the code:
while( iAll > 0 ) {
int iRcvd = m_KaboodleConnectionSocket.Receive( pReceiveTo,
iAll);
if (iRcvd == SOCKET_ERROR ) {
if (++iIndex > 30 ) return;
Sleep(/*:*/);
}
else {
pReceiveTo += iRcvd;
iAll -= iRcvd;
}
}
II. ENCRYPTION
Now, encryption is available of the data transmitted in the VNC session.
1. Problem description.
Previously, we had a raw data stream of non-wrapped packets between the
Kaboodle sockets. The destination party did not know the boundaries of the
packets and so could not select the blocks for decrypting.
2. The solution undertaken.
Now, the messages the two Kaboodle machines exchange in a VNC session are
wrapped into packets provided with a header. (see class Cpaket, files
Paket.h and Paket.cpp). The packet size is determined by the size of the
data portion sent by the VNC. The destination party waits for the entire
packet to be received then decrypts it and passes to the VNC. At present, we
apply the Kaboodle encryption method EncryptDecrypt(... "kUkKu") similar to
how it is done in the CSocketTCPIP class.
III. FAST-ACTING
1. A problem remaining.
After we implemented packet-base VNC data exchange, the total fast-acting
decreased. This is especially evident when moving the mouse: the cursor lags
behind.
2. What is to be done.
To get rid of this drawback, we are planning to substitute the 'Kaboodle' to
VncViewer socket connection to one, similar to implemented in VncListner.
(Note that socket class designed for a server would differ from the one
intended for a client.)
IV. TUNNELING
We still use a separate connection for VNC traffic tunneling.
1. A problem remaining.
The principles described in section I (VNC session stability) require a
specific socket read/write approach, which is quite different from what the
Kaboodle common still tube class CSocketTCPIP offers. Kaboodle connection
class has been originally designed to successive and not so intensive data
exchange as the VNC tunneling produces and it works fairly well with rather
small portions of data coming one by one. It is different with VNC when
intensive data streams are coming to and from the socket simultaneously.
2. What is to be done.
The whole Kaboodle connection must be redesigned.
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
