Accelerating CIFS Over
Satellite Networks
Muhamad Mjadleh
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Accelerating CIFS Over
Satellite Networks
Research Thesis
Submitted in partial fulfillment of the requirements
for the degree of Master of Science in Computer Science
Muhamad Mjadleh
Submitted to the Senate of
the Technion — Israel Institute of Technology
Tevet 5772 Haifa January 2012
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
The research thesis was done under the supervision of Prof. Roy Friedman
in the Computer Science Department.
I would like to thank the Technion family for the best supervisor I could
get, Roy, who walked me along through the three fascinating years I have
spent in this research. Roy, thank you for the support, the understanding,
the guidance and most of all, the opportunity to experience what enjoyable
research is. We would like to thank Moshe Carasso, Avi Gal, Nitay Argov,
and Ilan Ziv for many helpful discussions, ideas and suggestions, and for
helping us measure the proxy’s performance on Gilat’s satellite network.
The generous financial support of the Technion and the Ministry of Industry,
Trade and Labor under the NISAN Magneton Project is gratefully acknowl-
edged.
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Contents
Abstract 1
Abbreviations and Notations 2
1 Introduction 3
2 Related Work 6
3 Overview of CIFS 10
3.1 SMB Message Structure . . . . . . . . . . . . . . . . . . . . . 11
3.2 CIFS Message Exchange . . . . . . . . . . . . . . . . . . . . . 13
3.3 Opportunistic Locks (OpLocks) . . . . . . . . . . . . . . . . . 17
4 Accelerating CIFS 19
4.1 Proxy in details . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Message Recording . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Translating . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Write-back . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Results 27
5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 The Performance of the Proxy . . . . . . . . . . . . . . . . . 28
5.3 Experiments Over a Real Satellite Link . . . . . . . . . . . . 34
5.3.1 Experimental Setup . . . . . . . . . . . . . . . . . . . 34
5.3.2 The Performance . . . . . . . . . . . . . . . . . . . . . 36
5.4 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Discussion 40
i
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
List of Figures
1.1 VSAT network structure and the proxy placement . . . . . . 4
3.1 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Generic message exchange phases . . . . . . . . . . . . . . . . 13
3.3 Pipe binding’s message exchange . . . . . . . . . . . . . . . . 18
4.1 Sniffing of the locking phase with the Wireshark[4] sniffer . . 23
4.2 FID Translation . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 An example of faking TID. . . . . . . . . . . . . . . . . . . . 25
5.1 The shares tree the experiments were carried out with . . . . 28
5.2 Read file operation with fixed network delay and a variable
file size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Read file operation with variable network delay and variable
file size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Write file operation with variable network delay and fixed file
size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Simple browsing operations with variable network delay . . . 33
5.6 Variable network delay with variable browsing operations se-
quence length . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.7 Variable network delay with variable browsing operations se-
quence length . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.8 Read file operation with fixed network delay and a variable
file size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.9 Read file operation with a variable file size . . . . . . . . . . . 37
5.10 Variable browsing operations sequence length . . . . . . . . . 38
ii
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Abstract
CIFS (Common Internet File System) is the underlying protocol for Win-
dows file sharing system. CIFS requires a large number of unnecessary back
and forth message exchanges to complete a single request when it is pos-
sible to complete the request in fewer messages, therefore it operates very
poorly over WANs (such as satellite networks and other high latency and
high loss-rate networks).
This dissertation presents a proxy-based approach to CIFS acceleration
in satellite networks. In our proposed solution, the proxy acts like the files
server in the CIFS client side and the message exchange remains the same
from the CIFS client point of view. The client proxy selects the messages
to be forwarded to the server proxy and therefore we save multiple round
trips. The proxy operates according to a state machine to predict the client’s
operations and prefetches the server’s responses to the expected client’s re-
quests, this is possible because based on our analysis of the CIFS protocol,
the scenario in the message flow is mostly deterministic and could be man-
aged by the proxy’s state machine. The solution is light-weight, it requires
little memory space, is transparent to both client machines and servers, and
it fits into existing VSAT technologies aimed at developing countries. Per-
formance evaluation shows latency improvements by a factor of two in many
practical settings.
1
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Abbreviations and Notations
RTD — Round-Trip Delay
CIFS — Common Internet File System
SMB — Server Message Blocks
RPC — Remote Procedure Call
TID — Tree ID
FID — File ID
PID — Process ID
UID — User ID
MID — Multiplex ID
V SAT — Very Small Aperture Terminal
2
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 1
Introduction
During the last few years, there is a growing shift from stand-alone comput-
ing to data-center based computing. In the latter, data is stored in data-
centers and is accessed by its clients over the Internet and possibly other
wide-area network infrastructure. This tendency is fueled by the cost reduc-
tion, bandwidth enhancements and reliability improvements in networking
technologies, on one hand, and the security and ease of maintenance and
management of data in a data-center on the other hand.
In support of this trend, there is a need to make the perceived perfor-
mance of distributed file systems seamless and fast. Notice that even despite
the improvement in Internet latencies, the (RTD) over the Internet is still
orders of magnitude slower than local area networks. Moreover, in many
places in developing countries, as well as remote rural areas in North Amer-
ica, the only viable connection to the Internet is through a satellite link,
which inherently adds a 500ms RTD. Consequently, in order to accommo-
date these networks, distributed file systems must hide this long latency.
In this work, we are focusing on the CIFS protocol; CIFS is the default
Microsoft Windows distributed file system, and as such, is the most widely
used these days. By exploring the CIFS protocol, we have discovered that it
includes many inefficiencies, as detailed later in this dissertation. These are
caused by its chatty behavior, which includes many client-server synchronous
invocations as part of executing each client’s command.
Common techniques for accelerating distributed file systems include TCP
acceleration [9, 11, 13, 16, 17] as well as extensive file system caching on the
client’s LAN [8]. However, these are insufficient for our goal for the follow-
3
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Figure 1.1: VSAT network structure and the proxy placement
ing reasons: Accelerating TCP alone can expedite the transfer of very large
files. However, the inefficiencies in CIFS are at the basic protocol level, and
affect both the browsing of files and the opening of files. In these operations,
TCP’s flow control and congestion control mechanisms are not the perfor-
mance bottleneck in any case. As for extensive file system caching, due
to cost requirements, a client side satellite connection box, largely known
as (VSAT), cannot store too much data (see Figure 1.1). Moreover, given
the cost of satellite communication, it is prohibitively expensive to trans-
fer the amounts of data required to keep an entire file system cached and
synchronized at the client’s side.
Hence, our goal in this work is to find an acceleration mechanism for
CIFS that eliminates its chatty behavior over the satellite link (or in general,
any long haul/WAN link). Yet, at the same time, the mechanism should
be non-intrusive, in the sense that it should not require installation on any
client’s machine. Our solution is based on the observation that all satellite
4
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
communication goes through a VSAT at the client’s side, as illustrated in
Figure 1.1. Hence, we are looking for a proxy based solution, in which
the proxy resides in the VSAT. In such a solution, the proxy at the VSAT
breaks the communication between the client and the data-center in two,
and whenever possible, attempts to provide immediate local replies to the
client. Yet, in doing so, it must take care in order to maintain the correct
file system semantics w.r.t. the data-center.
In this dissertation, we report on our analysis of the CIFS protocol and
the proxy based solution we have developed, as well as a performance eval-
uation. Our solution is non-intrusive to the clients’ machines, yet obtains
latency improvements of 50% even without any TCP acceleration and data
caching. Our solution is light-weight and requires very little space, and
hence can easily fit into existing VSAT technology.
Dissertation’s road-map: We discuss related work in Section 2. Sec-
tion 3 presents the CIFS protocol and introduce its inefficiencies. We de-
scribe our proxy solution in Section 4. The results of experiments appear in
Section 5 and we conclude in Section 6.
5
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 2
Related Work
As mentioned in the Introduction, there are several known TCP acceleration
techniques. Yet, they are not sufficient for our goals, since they do not
address the CIFS protocol inefficiencies. Yet, as these techniques can work in
addition to protocol acceleration, to expedite large file transfers, we describe
some of them below:
1. Reducing the slow start stage or even start sending messages as fast
as possible until data is lost and then slowing down [17].
2. Satellite and wireless networks tend to experience a high error rate.
This increases the observed latency due to the resulting retransmis-
sions. A partial solution is to increase the transmitter’s power or to
use larger antennas. However, this solution is expensive and requires
special hardware installation [13].
3. Forward Error Corrections Schemes: another alternative for reducing
error rate is using error correction [16]. The cons of this technique are
the fact that it requires padding additional data and also, this does
not solve other major problems such as TCP slow start.
4. TCP window size scaling: The default TCP window size representa-
tion is limited to 16 bits, which is not adequate for satellite networks.
The proposed option allows connections to negotiate a scaling fac-
tor at startup. This solution can cause sequence number wraparound
problems and a special mechanism is needed to handle that prob-
lem [13, 17].
6
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
5. Cascading TCP: dividing a single TCP connection into multiple TCP
connections [11].
6. Selective Acknowledgments technique: this technique allows TCP re-
ceivers to inform TCP senders exactly which packets have arrived.
The goal here is fast recovery from lost segments [13].
Several works have concentrated on the CIFS protocol itself. The SkyX [7]
application uses several techniques to accelerate file transfer over WANs.
The most prominent of them is compressing the file on the server side and
uncompressing it at the client. The Silver Peak NX [6] appliance uses net-
work memory to reduce the amount of repetitive information that is sent
across the WAN. Both solutions can help in the case of transferring large
files, but not for other operations.
Many other solutions were suggested such as prefetching and caching.
For example, the Juniper Networks [8] solution implements a combination
of compression and caching with TCP acceleration and more. The perfor-
mance benefits and tradeoffs of the Juniper Networks solution was studied
by van Helmond and Smeets [20]. They have shown that Juniper’s CIFS ac-
celeration works well in high bandwidth high latency links. Notice, however,
that satellite links often have relatively low bandwidth. In our solution, the
performance increase factor is independent of the link’s delay and is obtain-
able even over low bandwidth links.
The Comtech EF [9] data product implements Quick Start, Window
Scaling, Intelligent Congestion Control, Rate Racing (meters out burst traf-
fic at a rate not to exceed the configured transmission rate of the satellite
channel) and Selective Negative Acknowledgments.
The F5 WANJet CIFS acceleration solution [2] pre-fetches data when
it determines a transaction is likely to occur. Yet, it may happen that a
pre-fetch was done unnecessarily, as the ability to guess if a transaction will
occur is inaccurate; in such cases, pre-fetching only wastes bandwidth. In
addition, it helps reduce the latency but not the redundancy of CIFS.
There are several protocols, other than CIFS, that also suffer from re-
dundant network traffic. A solution to this problem was introduced in [18],
where the combination of Web proxy caching with redundancy suppression
is proposed. Yet, their solution is not suitable for CIFS, and also requires
large memory to be effective.
7
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Layland has introduced an Application Delivery Architecture [15] to se-
cure and accelerate protocols. It is based on a proxy and full message inspec-
tion. Some of the methods used in Layland’s work include (a) compression,
(b) QOS/DiffServ (Quality of service), (c) path reduction, i.e., when au-
thentication is required, in normal flow, the authentication request is sent
to the file server and the server forwards the request to the authentication
server, whereas in path reduction, the proxy sends the request directly to
the authentication server, (d) SSL offload, i.e., implementing SSL processing
in hardware, which is faster, (e) caching, and (f) TCP acceleration.
There are also several US patents that deal with acceleration, for exam-
ple:
• The solution in [19] is composed of server-side handler and client-side
handler, where each handler stores segments of data in the transactions
in persistent storage. The storage resembles a cache stored in two
copies, one on the client handler side and another on the server’s one.
The storage in both sides is synchronized. If a data segment needs to
be sent from one handler to another, a reference to the data segment
in the storage is sent instead and therefore, less bandwidth is used on
the link and the translation is done faster. The storage itself is only
updated when the data is needed on its side.
• The patent application of [10] proposes a solution composed of servers
forming an application service deliver points (SDP). The nodes in the
network are assumed to be capable of accelerating. The network is
located between the client and the server and the nodes in the network
are client SDP’s and server SDP’s. The SDP’s accelerate the TCP
connection with known TCP acceleration techniques.
As mentioned in the Introduction, Caching schemes are mostly useful
for reducing the latency of a repetitive access to a file, but not for the
initial access. Meta-data pre-fetching and caching can help resolve this,
but require large data storage and frequent synchronization communication
with the data-center, which is costly over a satellite link. Our work deals
directly with some inherent wastefulness in the CIFS protocol. In particular,
it dramatically improves the user’s experience in browsing folders and first
access to a file. As discussed later, our approach may be generalized to
work with additional TCP-based protocols. In addition, it only requires
8
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
installing a software component on the client’s VSAT (or gateway) without
any modifications of the client’s LAN topology or any hardware addition.
Also, this is done completely transparently to the client and server machines.
9
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 3
Overview of CIFS
CIFS [1, 14] is a remote file access protocol that follows the client/server
interaction style and forms the basis for windows file sharing. It is also used
as a transport protocol for various higher level Microsoft communication
protocols, as well as for network printing, resource location services, remote
management/administration and network authentication (secure establish-
ment services). In addition, CIFS is implemented for various operating
systems such as UNIX and Linux [5]. There is also an implementation of
CIFS in JAVA [3]. CIFS is based on SMB (Server Message Block), which
was developed in the early 1980’s. SMB defines both server and client be-
havior. When a client initiates a request on a remote server, it negotiates the
version of the SMB protocol they will follow in that particular session. The
SMB protocol versions are called dialects and correspond to OS’s releases
and updates. In our work we refer mostly to the NTLM 0.12 dialect.
The drawbacks of CIFS are related to the chatty nature of SMB. That
is, some queries overlap and some are repetitive. This situation is partic-
ularly aggravated in the Windows CIFS implementation. The latter sends
identical requests and queries several times in a given message exchange
thereby wasting unnecessary back and fourth messages. Given that each
such exchange is performed as a synchronous RPC, the latency experienced
by users over satellite and other high-latency links is intolerable.
We assume that this behavior is somehow related to the storage tech-
nology and architecture that was common in the early 1980’s, when SMB
was first introduced. Furthermore, SMB was designed and initially run only
over the network layer NETBIOS, which is primitive and simple and was
10
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Byte 1 Byte 1 Byte 2 Byte 3
Zero
0xff ’S’ ’M’ ’B’
Command STATUS...
..STATUS FALGS FLAGS2
EXTRA..
TID PID
UID MID
Words
ByteCount
Bytes
WordCount
SMB Length
Para
met
ers
Dat
aH
eade
r
NE
TB
IOS
SMB
Figure 3.1: Message Structure
designed for local networks that exhibit low latency. Hence, developers were
not worried about the round trip time. CIFS still runs on modern NETBIOS
which is now implemented over TCP/IP on ports 139/445. These ports are
reserved for NETBIOS in Windows OS’s. NETBIOS wraps SMB messages
with 4 bytes headers.
Unfortunately, Windows CIFS’s implementation documentation is not
fully available. Also, the protocol specification is incomplete, inconsistent,
and is often published by third-party which are not official Microsoft doc-
uments. This is a problem for CIFS third-party developers (e.g SAMBA)
without mentioning the variety of SMB dialects. Interestingly, the SAMBA
implementation of CIFS is much more parsimonious.
3.1 SMB Message Structure
SMB’s messages are composed of three main parts, as illustrated in Fig-
ure 3.1: a header, a parameter block and a data block. We start by describing
11
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
the header fields:
• PROTOCOL: The first 4 bytes of an SMB message are always set to
the values 0xff,’S’,’M’,’B’.
• COMMAND: The SMB command type, e.g., read command, create
file command, etc.
• STATUS: Used for error handling and specifying SUCCESS/FAILURE.
• FLAGS and FLAGS2: These fields are interpreted and set by the
client/server. One of this field bits is used to indicate whether the
messages is a request or a reply1.
• EXTRA: Used for supporting extensions to the basic SMB protocol,
for example, for holding the messages signatures if the conversation
supports signing the SMB messages. This field is set to zero when not
used.
• TID: The client connects to a specific tree (a share name, which repre-
sents a directory or subdirectory) with CONNECT TREE REQUEST.
When successful, it receives CONNECT TREE REPLY with the client
allocated TID, which the client will subsequently use when referring
to the specific share.
• PID: Set by the client to identify the process sending the request. This
field is relevant for example in file locking. This value is not necessarily
the real process ID.
• UID: Assigned by the server to the client after successful login and is
valid until logout.
• MID: Set by the client to match responses to requests. It is used to
allow multiple outstanding client requests to exist without confusion.
For the purpose of our work, the TID and MID fields are the most
significant. Query requests suffer the most from CIFS’ redundancy. In
1Generally, the client initiates sending a message except two cases in which the serverinitiates the sending: (1) when breaking Opportunistic Locks, as will be introduced laterin this section, and (2) when notifying the client about changes on files with an SMBNOTIFY command, as will be discussed in the next section.
12
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
In this phase, the UID is allocated
Authentication process
Disconnect and Logoff
CIFS dialect negotiation (only when a new connection is established)
CIFS session creation
Client operation’s specific commands
Initiating TCP connection (can be skipped if already opened)
Figure 3.2: Generic message exchange phases
these requests, the client asks for properties about the file/directory. Some
of these queries are sent only after retrieving an FID for the file and others
can be sent also by specifying the file path and name. In a query, the client
sets the information level it wishes to obtain. Examples of such queries are
ALL FILE INFO, FILE BASIC INFO,FILE STANDARD INFO, etc. The
server echoes those fields in the responses. They are used by the client and
server to keep track of the context of the current conversation.
3.2 CIFS Message Exchange
Each CIFS operation invoked by the user is translated to one or more CIFS
command requests. The message exchange is divided into five basic phases,
as shown in Figure 3.2:
• TCP Connection establishing: Standard TCP Connection creation,
13
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
which is composed of 3 handshakes. SMB runs over NETBIOS. There-
fore, the session is established on ports used by the NETBIOS protocol
(ports 139/445 on the server).
• Negotiation: The NEGOTIATE PROTOCOL REQUEST/RESPONSE
is always the first SMB exchange in the conversation. The client and
server need to know what dialect to speak before they can say any-
thing else. Most Windows clients support at least six different dialects
of Microsoft’s SMB protocol. The client suggests several dialects that
it is capable of speaking and the server selects the highest dialect it
is capable of speaking. The NEGOTIATE PROTOCOL REQUEST
also specifies the server capabilities and configuration such as case
sensitivity, security modes, maximum buffer size, etc.
• Session Creation: In this phase, CIFS runs the authentication and
logging process. The security model used in Microsoft SMB Protocol
is identical to the one used by other variants of SMB, and consists
of two levels of security, namely, user and share. A share is a file,
directory, or printer that can be accessed by Microsoft SMB Protocol
clients.
In the NT LM 0.12 dialect, which is the most recent dialect, there
must be a SESSION SETUP exchange negotiation phase. The au-
thentication process in SMB depends on the server capabilities and
the dialect. It could be plaintext password, anonymous login or chal-
lenge/response. The most common authentication scheme is done
within four messages via Microsoft’s NTLMSSP authentication service
which is based on a variant of the challenge response protocol. The
login phase is irrelevant to our work as it is impossible to accelerate it
without breaking the system’s security.
After a successful login process, a UID is allocated to the user. The
UID is per point-to-point session. In other words, if one is connecting
from one point to another and before the session ends, the other point
is connected again, the new connection will get the same UID.
In addition, authorizing and connect tree messages may be sent more
than once during the message exchange due to different security levels.
• Operation specific commands: For each user operation, a different
14
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
message exchange occurs in this phase. For example, for a file read
performed from the Windows Command Prompt, the commands sent
are:
– Opening the file and locking it.
– Reading part of the file’s data.
– Obtaining file information.
– Reopening the file and refining the locking level.
– Obtaining file information again.
– Reading the file’s remaining data.
The interesting thing about this stage is the redundant data in the
message exchange. The same queries are asked several times and same
data are read twice. For browsing, additional commands are involved:
if the client accesses a share X (double click on the folder icon), the
CIFS implementation in windows sends a TREE CONNECT, PATH:
\\SERVER\X first.
After the user session is established, the client connects to a share
using TREE CONNECT. If the client is connecting to the server, it
requests to open a tree with the server name at the top. It sends ”Tree
Connect Request, Path: \\SERVER\$IPC”.
IPC (Inter Process communication) is a set of techniques for the ex-
change of data between two or more threads in one or more processes.
The server replies with TREE CONNECT RESPOND containing the
TID allocated. In Browsing, the second stage contains the following
features, as illustrated in Figure 3.3:
– Binding WKSSVC pipe name through the DCE/RPC.
– Binding SRVSVC pipe name through the DCE/RPC.
– Binding SPOOLS pipe name through the DCE/RPC. In case of
printing.
– Binding WINREG pipe name through the DCE/RPC.
CIFS first opens the pipe, reads data, writes data, and then gets in-
formation about the server station such as:
15
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
– Is it a workstation?
– Is it a server?
– Is it an SQL server?
– Is it an Apple host?
– Server Name (which is often SERVER).
– Domain Name (which is often WORKGROUP).
– and more.
This process is repeated several times for the pipes WKSSVC/SRVSVC.
Notice that the client requests are the same, as are the server responses.
They only differ in their FID value (recall that FID is the identifer for
files as TID is for trees).
If the client invokes a simple read/write file operation (on the Windows
Command Prompt), the command processor translates this operation
into multiple SMB commands as listed above, yet without binding to
the pipes.
A CONNECT TREE REQUEST may be sent with one of the values
in the following table:
String Meaning
A: A filesystem share
LPT1: A shared printer
IPC An interprocess communications named pipe
COMM A serial or other communication device
????? Wildcard
• Disconnecting and logoff: If the read operation in the Windows Com-
mand Prompt is completed or the Windows Explorer window is closed,
then the client disconnects from the shares it is connected to. The
only tree kept connected to is the \$IPC, which is disconnected after
a timeout. If another operation is invoked within the timeout then
there is no need to connect to \$IPC. The Logoff message is sent after
a timeout (shorter than the $IPC timeout) passes since the operation
completed. Therefore operations invoked within the timeout will use
the same session and will not require authentication.
• logoff: Sent after a disconnect command.
16
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
3.3 Opportunistic Locks (OpLocks)
OpLocks are locks granted to clients from an SMB server when it opens a
file. This is useful in write-back algorithms to save latency. There are two
types of oplocks:
Exclusive oplocks allows a client to open a file for exclusive access and
allows the client to perform arbitrary buffering.
Batch oplocks allows a client to keep a file open on the server even though
the local accessor on the client machine has closed the file.
Level II oplock indicates that there are multiple readers of a file and no
writers.
Oplocks in CIFS are involved, yet well documented [14]. We will only men-
tion the oplock break option. When a client opens a file, it requests the
server to grant it a particular type of oplock on the file. The response from
the server indicates the type of oplock granted to the client. The client uses
the granted oplock type to adjust its buffering policy. The LOCKING SMB
command is used to convey oplock break and response information.
17
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Open Pipe request
Open Pipe response
Bind Pipe request (Which is SMB write command)
Bind Pipe response
Bind Pipe Ack request (Which is SMB read command)
Bind Pipe Ack response
RPC function call request (Which is SMB Trans command) RPC function call response
Close pipe request
Close pipe request
Client Server
Figure 3.3: Pipe binding’s message exchange
18
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 4
Accelerating CIFS
As mentioned before, in our proposed solution, we break the session between
the client and the server and place a proxy in the middle (inside the VSAT
on the client’s LAN). From the client’s point of view, the proxy acts like the
file server. The proxy examines the client’s messages sent to the server in
order to decide whether it should forward these messages (potentially, with
some modifications) or if it is possible to answer the client locally without
referring to the server. See illustration in Figure 1.1.
The proxy is transparent to both client and server and they continue
to run their unmodified CIFS implementation. The proxy does not add
any traffic beyond the client needs. In fact, the proxy may even reduce
the bandwidth consumption over the satellite link, as it tries to reduce the
number of round trips over this link. In practice, upon receiving a client’s
request in the proxy, two sessions are maintained, one between the client
and the proxy, and another that the proxy opens with the server. The
sessions are managed by a state machine that follows the client’s message
flow. This state machine is driven by the content of the messages received.
The following describes the proxy general algorithm.
In some SMB responses, the responses are sent only to indicate success
and do not contain information about the files on the server. For example,
when a client sends a DISCONNECT request from a tree, the client waits
to receive the success response and wastes time. In this case, it is possible
to return control to the client immediately, as it is certain the client will
not refer to a tree through the disconnected parameters. In such requests,
the proxy answers the client immediately with SUCCESS and completes
19
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Algorithm 1 The proxy algorithm
Initialize global parametersWAIT:wait for connections from clientsconnection established with a clientgo to WAIT and execute the following in parallelcreate connection, initialize local parameters and connect to the serverloop
receive a message from the clientexamine the message and decide on next state according to current stateand the received message fieldsprocess message and store relevant datapreform new prefecthing if possible in new thread in parallelif request can be answered locally then
create response message and send it to the clientforward the client’s request message to the server if necessary
elseforward the client’s request message to the server, possibly withhigher information levelwait for a reply from the serverexamine the message and decide on next state according to currentstate and the received message fieldsprocess message and store relevant datapreform new prefecthing if possible in new thread in parallelcreate a response message based on the server’s response and send itthe client
end ifend loop
20
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
the disconnecting process with the server later. This approach is used also
in requests that change the files states such as WRITE and SET INFO,
but these situation are handled with more caution as a violation of the
persistency could occur, e.g., if the client sends a WRITE request, the proxy
replies the WRITE request with success and forward the WRITE request,
but then, the proxy fails without confirming the WRITE request success on
the server.
4.1 Proxy in details
The proxy acceleration model has two main mechanisms:
State machine: A state machine tries to match the client’s message flow
to pre-specified state machine patterns (paths). If there is a match,
the proxy can predict the operation the user is performing. Therefore,
it can predict what the next message will be, and perform pre-fetching.
Another nice addition would be to pre-fetch two paths or more if re-
ducing the delay is more important than bandwidth. It is a matter of
time/bandwidth tradeoff.
Local answering: Here, whenever possible, the proxy locally computes the
response the client is expecting based on previously recorded informa-
tion. The response the proxy construct is the same response the server
would reply if the request had been forwarded to it.
These two mechanisms work simultaneously. If the proxy fails to keep
track of the client operation and the state machine is not capable of following
the message exchange further, the local answering mechanism will still try
to accelerate CIFS. Local answering is enabled by the following techniques:
4.1.1 Message Recording
The proxy records all message parts to be used later in computing replies
locally without referring to the server. The granularity in the recording is
a single field. In other words, we record the fields from different messages
and try to build responses locally with these parts. This approach resembles
caching, yet here we cache message fields rather than file’s data.
21
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Recall the message structure as described in Section 3. Hence, messages
can be viewed as frames of fields of known types (integer, time, boolean, etc).
The proxy analyzes the message and divides it to its fields, each treated as
a sequence of char-sets. This is more powerful than recording full messages,
as it enables the proxy to answer queries not seen before, but whose reply
consists of already recorded fields from previous queries. This scenario is
possible because the set of fields of several CIFS query commands may
overlap and even be contained in each other.
When the proxy receives a query for attributes with a given information
level, and the attributes are not already stored at the proxy, it sends to the
server a query request with a more exhaustive information retrieval level.
This results in a response containing even more information than the client
asked for. For example, if the proxy receives a query request with infor-
mation level of FILE BASIC INFO, it sends a FILE ALL INFORMATION
query request, which also contains all attributes of FILE BASIC INFO. The
proxy then parses the response from the server to answer the client with the
information it asked for and stores the additional information for future
usage. This way, the proxy gets more information without an additional
latency, yet with little extra bandwidth. This is motivated by the standard
message flow of CIFS, in which the client later asks for the additional in-
formation. This information is stored for a finite period of time to keep our
memory space from overflowing. Files data is also cached for a specified
time due to the locality principle.
4.1.2 Translating
Surprisingly, CIFS opens the same file (through the command CREATE
FILE with the option “if file exist open it, else fail” set) over and over again
more than once on the same session. Later it could refer to the same file
using any of the FID’s it received. For example, in Figure 4.1, we are sniffing
simple remote 4KB read file on the Windows Command Prompt. The file
is opened for reading with appropriate permissions granted Batch oplock.
After that and before closing the file, the CIFS client requests information
on the file and then tries to reopen the file for reading, but the file is locked.
Therefore the server sends locking break LOCKING SMB command to the
client with a MID of 0xffff and waits for a successful response from the
22
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
192.168.164.130 192.168.164.129 NT Create AndX Request, Path: \file1.txt192.168.164.129 192.168.164.130 NT Create AndX Response, FID: 0x4000192.168.164.130 192.168.164.129 Trans2 Request, QUERY_FILE_INFO, FID: 0x4000, Query File Internal Info192.168.164.129 192.168.164.130 Trans2 Response, FID: 0x4000, QUERY_FILE_INFO192.168.164.130 192.168.164.129 Read AndX Request, FID: 0x4000, 4096 bytes at offset 0192.168.164.129 192.168.164.130 Read AndX Response, FID: 0x4000, 4096 bytes192.168.164.130 192.168.164.129 NT Create AndX Request,Path: \file1.txt192.168.164.129 192.168.164.130 Locking AndX Request, FID: 0x4000192.168.164.130 192.168.164.129 Locking AndX Request, FID: 0x4000192.168.164.129 192.168.164.130 NT Create AndX Response, FID: 0x4001192.168.164.130 192.168.164.129 Trans2 Request, QUERY_FILE_INFO, FID: 0x4001, Query File Standard Info192.168.164.129 192.168.164.130 Trans2 Response, FID: 0x4001, QUERY_FILE_INFO
Source Destination Info
Figure 4.1: Sniffing of the locking phase with the Wireshark[4] sniffer
client and then allocates FID to the second open request. In our solution,
the second request is answered successfully with a fake FID without breaking
the oplock granted to the first open request. This solution works fine because
the second FID is not used in the flow at any stage. The only reference is
when closing the file. We do not know the source of this weird CIFS behavior.
Our solution also works when a CIFS client wishes to open a file that is
already opened or even recently closed1. When the proxy answers the open
file response locally, it allocates a fake FID and includes it in the response
with the stored file response parameters. In tandem, the proxy sends an
open file request to the server if no open session with the file already exists.
Later, in each request referring to the fake FID allocated by the proxy that
cannot be answered locally and therefore must be forward to the server, the
fake FID is translated into the actual FID allocated by the server. Figure
4.2 demonstrates this mechanism.
The same technique could be applied to the TID identifier. While this
is possible, it is not nearly as effective since after obtaining a TID for a
share, the client often immediately sends requests referring to the faked
1The open response includes the FID allocated and information on the file (useful inanswering queries later) and oplock type.
23
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Create x
Create x
FID = 1000
FID = 1000
Create x
FID = 2000
Query on FID = 2000
Query on FID = 1000
Response FID = 1000
Response FID = 2000
Proxy ServerClient
Figure 4.2: FID Translation
TID. Meanwhile, the proxy cannot translate the fake TID to an actual TID
because there is no TID allocated from server yet. Therefore the saving here
are negligible. Figure 4.3 illustrates this scenario with an example in which
faking a TID is not very effective. Here, the network delay between client
and proxy is 10 msec while between proxy to server it is 250 msec. The
computation time in the proxy is 1 msec. The obtained reduction in latency
is only (1024-1013)=11 msec.
4.1.3 Write-back
Requests that change the files’ states (such as WRITE and SET FILE
INFO), are answered with success immediately and forwarded to the server
to save the delay of the round trip to the server. Furthermore, DISCON-
24
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0
11
56
16
256
506507
757
10071008
1013
6 5
256
506507
518517
768
1018 1019
512
1024
0
ClientClient Proxy Server Proxy Server
TID Translation On TID Translation Off
Figure 4.3: An example of faking TID.
NECT and LOGOFF requests are answered too with success and forwarded
soon. CLOSE requests are answered with success but requests are not for-
warded to the server immediately. Instead, they are forwarded only after
a timeout from the last reference to the file, i.e., the timeout is reset each
time a request accesses the file . This technique is helpful as we adapt the
locality principle, because this file may be re-opened soon in the near future.
Challenges A problem could arise due to client’s modifications such as
write cache. In this case, we answer locally with success, update the stored
data in the proxy and forward the data to the server to keep it up to date.
On the other hand, external modifications are possible too such as another
25
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
client changing the file attributes. We solve this with the NOTIFY SMB
command. This command notifies the client when the directory specified by
FID is modified2. This command may be used to begin watching files and
subdirectories in the specified directory for changes.
The proxy is multi-threaded and could serve several clients concurrently.
Each client is handled in several threads to achieve maximum effectiveness.
For example, for a given client, the proxy allocates two buffers, one for
receiving messages and another for sending messages while on the server
side, buffers are allocated on demand and are synchronized (using mutexes
[12]) to one sending buffer and one receiving buffer. The multiplexing of the
received messages is done by the MID field in the SMB command. This is
possible because each request in CIFS has a different MID so the client can
correlate responses to requests according to the MID value.
2A case of a message sending event being initiated by a server.
26
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 5
Results
This section presents the performance evaluation of the proxy. We start with
results obtained using a network simulator that simulates a satellite link in
our Lab. Next, we show results of experiments conducted in GILAT’s labs
over a true satellite link on large servers to verify the results of the simulator
and to test the proxy robustness.
5.1 Experimental Setup
Our testing environment consists of a server, a client and the proxy. The
server and client were run on two Lenovo machines, each with Intel T2140
Core 2 Duo with 2048 MB 667 MHZ RAM running Windows XP SP3.
The proxy was implemented in C and executed on a Lenovo ThinkPad T61
laptop with Intel T7500 Core 2 Duo Processor with 2048 MB 667 MHZ RAM
running the Ubuntu Linux OS. The network cards are all Gigabit adapters
and all machines were connected via a Fast Ethernet switch. We installed
the Wireshark sniffer on the client OS.
We measure the duration of an operation as the difference between the
time at which the client received the last message corresponding to this
operation and the time in which the first message for this operation was
sent by the client. These values are extracted from the Wireshark output.
In order to measure the impact of network latency on operation durations
with and without the proxy, we have simulated WAN latencies using the
Ubuntu Netem application by adding fixed delays to the SMB packets that
27
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Figure 5.1: The shares tree the experiments were carried out with
are forwarded to the server. The link between the proxy and the server
simulates the slow link.
Each measurement point is an average of 10 measurements of the same
operation repeated to lessen noise influence. In each figure, we also calcu-
lated the relative standard deviation. The experiments are carried out in a
typical work-group station with varied file types. Figure 5.1 illustrate the
shares’ tree we worked with.
5.2 The Performance of the Proxy
The results for a read file operation are given in Figure 5.2. This test is per-
formed by invoking copy \\SERVER\DIRECTORY\REMOTE FILE NAME
LOCAL FILE NAME in the Windows Command Prompt. In this batch of
experiments, we set the network delay to 150 msec (round trip is 300 msec)
and changed the file sizes that are copied by changing the REMOTE FILE NAME.
The X-axis stands for the file size.
The graph demonstrates that up to 4KB, the duration of a file read
28
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
operation is not affected by its size. This is true both with the proxy and
without it and is attributed to the fact that up to 4KB fit in one SMB packet
and therefore the same message exchange occurs for these operations. We
also notice that the saving obtained through the use of a proxy is fixed and is
independent of the file size, i.e., the gap between the two curves is constant.
In other words, the time period for a read file operation for different sizes
includes a fixed component plus the time needed to transmit the file’s data
segments. In addition, the message flow of a read file operation is short and
is not long enough to increase significantly the TCP window size and file
data packets must be acked.
Another interesting point is that the difference between reading 20KB
and 1/2/4 KB (both with and without proxy) is only 150 msec, which is
a one way trip and not a complete round trip. This is because the READ
command can ask for the entire data in one message, and the server can
send this data using two read responses within the TCP window without
waiting for an ack.
The impact of varying the network latency on file read operations is
shown in Figure 5.3. This experiment is similar to the last one except
that here we simulate different network delays. The X-axis stands for the
simulated network delay. As can be seen, the higher the network latency is,
the more significant is the improvement. Again, the file size has no influence
on the operation time. However, the improvement ratio is reduced because
the data’s transfer process becomes longer and the proxy’s savings becomes
less dominant. In addition, we see again that the latency of read operations
for 1/2 KB files’ sizes are almost identical.
Figure 5.4 reports on the same experiments conducted with a file write
operation. The X-axis stands for the simulated network delay. We can see
similar phenomena to the ones reported above.
In the last two batches, we explore browsing operations. Figure 5.5
shows the timing results of simple two sequential browsing operations. In
each experiment of this batch, we connected to the server and then clicked a
directory in the browser. The X-axis stands for the network delay simulated.
As can be seen from the graphs, the gain is significant in the initial stages
when CIFS enters a share. This result corresponds to our expectations, since
as we described before, CIFS opens the pipes in this stage and this process
includes remarkable redundancy. Therefore the potential for improvements
29
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 10 20 30 40 50 60 70 800
500
1000
1500
2000
2500
3000
3500
4000
4500
file size (KB)
time(
ms)
Time of read file operation
with proxywithout proxy
Figure 5.2: Read file operation with fixed network delay and a variable filesize, the relative standard deviation in this batch was below 0.27%
30
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 50 100 150 200 2500
1000
2000
3000
4000
5000
6000
7000
link delay simulated (ms)
time(
ms)
Time of read file operation
1KB with proxy1KB without proxy2KB with proxy2KB without proxy20KB with proxy20KB without proxy
Figure 5.3: Read file operation with variable network delay and variablefile size, the relative standard deviation in this batch was below 12.80%
31
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 50 100 150 200 2500
1000
2000
3000
4000
5000
6000
link delay simulated (ms)
time(
ms)
Time of write file operation
with proxywithout proxy
Figure 5.4: Write file operation with variable network delay and fixed filesize, the relative standard deviation in this batch was below 0.51%
32
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 50 100 150 200 2500
10
20
30
40
50
60
link delay simulated (ms)
time(
min
s)
Time of simple browse operations
with proxywithout proxy
Figure 5.5: Simple browsing operations with variable network delay, therelative standard deviation in this batch was below 4.33%
by the proxy is very high.
The results of a much more involved browsing sequence are given in
Figure 5.6. In this batch, the length of the browsing operation sequence
increases. Each line in the graph represent specific network delay and the X-
axis stands for the sequence length. Recall that the proxy caches information
it hears (at a granularity of a single message field). Therefore, as expected,
the proxy yields better improvement as the operations sequence prolongs.
However, the most significant improvement is for the first stage, which is
entering the share. As the number of browsing operations increases, the
ratio of the improvement is reduced. This is due to the high cost of entering
a share compared with other operations.
Another angle of the above is presented by Figure 5.7, which follows the
ratio of performance improvement obtained by the proxy as a function of the
browsing sequence length. We notice that these curves have a peak around
40 operations. This peak is created for the following reason: initially, as
the number of operations increase, the cache gets more hits as there are
33
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 20 40 60 80 100 120 140 1600
10
20
30
40
50
60
70
80
browsing sequence length
time(
min
s)
Time of browse operations operation
30 with proxy30 without proxy180 with proxy180 without proxy300 with proxy300 without proxy
Figure 5.6: Variable network delay with variable browsing operationssequence length, the relative standard deviation in this batch was below
5.34%
browsing operations (locality principle), but still, this added benefit from
this caching is less significant than the initial stages save, and it take about
40 operations to compensate and improve the save ratio.
5.3 Experiments Over a Real Satellite Link
To verify the results obtained in our labs, we tested our solution in real
satellite networks, we repeated part of the experiments. We used the same
tools and the same method for measuring the operation duration. Only the
network layout and the machines were changed.
5.3.1 Experimental Setup
Similarly, our testing environment consists of a server, a client and the proxy.
the server and client were run on two machines, each with Intel Pentium(R)
34
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 20 40 60 80 100 120 140 1600
10
20
30
40
50
60
browsing sequence length
perc
enta
ge %
Save ratio in browse operations
30 msec180 msec250 msec
Figure 5.7: Variable network delay with variable browsing operationssequence length
35
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 10 20 30 40 50 60 70 80 900
2000
4000
6000
8000
10000
12000
14000
16000
file size (KB)
time(
ms)
Time of read file operation
with proxywithout proxy
Figure 5.8: Read file operation with fixed network delay and a variable filesize, the relative standard deviation in this batch was below 9.54%
D CPU 3.20 GHz with 512 MB RAM running Windows XP SP2. We used
the same machine for the proxy.
The average round trip over the satellite link is 700 msec. Each measure-
ment point is an average of 3 measurements of the same operation repeated
to lessen noise influence. In each figure, we also calculated the relative stan-
dard deviation. The relative deviation were larger as the link is divided
into segment and the bandwidth available is about 1MB, in addition, other
traffic except hours is transmitted on the link.
5.3.2 The Performance
The results for a read file operation are given in Figure 5.8. This test is per-
formed by invoking copy \\SERVER\DIRECTORY\REMOTE FILE NAME
LOCAL FILE NAME in the Windows Command Prompt.
In this batch of experiments, we changed the file sizes that are copied by
changing the REMOTE FILE NAME. The X-axis stands for the file size.
36
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
0 10 20 30 40 50 60 70 80 900
2000
4000
6000
8000
10000
12000
file size (KB)
time(
ms)
Time of write file operation
with proxywithout proxy
Figure 5.9: Read file operation with a variable file size, the relativestandard deviation in this batch was below 7.15%
37
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
1 1.5 2 2.5 3 3.5 4 4.5 510
20
30
40
50
60
70
80
operations counter
time(
min
s)
Time of browsing operations
with proxywithout proxy
Figure 5.10: Variable browsing operations sequence length, the relativestandard deviation in this batch was below 11.86%
Figure 5.9 reports on a file write operation. The X-axis stands for the
file size. In the last batch, we repeated the browsing operation sequence
length experiment, but with fixed network delay which is the satellite round
trip (700 msec). The operation sequence is the following:
• Connecting to the server.
• Browsing folder1.
• Browsing folder1\folder2.
• Backward.
• Browsing folder1\folder2.
Figure 5.10 presents the time for browsing time for each prefix of the se-
quence. The X-axis stands for the sequence length. As can be seen the proxy
latency improvement ratio in GILAT labs is identical to the one obtained in
our labs.
38
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
5.4 Robustness
The proxy may fail to follow client’s messages and match them with a path
in the state machine. This may result either from unpredicted user behavior,
bugs, or link failure (message loss). As mentioned before, the proxy does a
best effort to minimize the traffic to the server by benefitting from its local
answering mechanism, while trying to find a new match. This ability has
been verified.
CIFS relies on TCP/IP. TCP guarantee delivery of the CIFS messages
and CIFS does not implement message loss recovery mechanism. When a
message is lost, CIFS sends an ECHO message, closes the connection and the
operation is not completed. When a message is lost in the proxy, the proxy
continues to wait for the lost message and after a timeout the client’s request
is not replied the CIFS client sends the ECHO and closes the connection.
39
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Chapter 6
Discussion
In this work, we have demonstrated the viability of the proxy approach for
accelerating CIFS at the protocol level. Our mechanism is light-weight, and
therefore can fit existing VSAT technology aimed at developing countries
and remote rural areas. It successfully eliminates redundancies and chatti-
ness from the long-haul link of CIFS transparently to both client and server
machines. This is especially important for browsing folders, first file access,
and opening small files. Our approach is orthogonal to TCP acceleration
and data caching. Hence, it can be combined with those in order to improve
all aspects of remote file accesses.
The memory consumption can be controlled by the proxy operator or
vendor. This can be done either by setting the timeouts for the validity of
stored data, or placing a hard space limit, based on the amount of memory
available at the VSAT. The proxy adds a small computational overhead to
each message, as it needs to intercept it and parse it. Yet, this overhead is
negligible.
It may be possible to extend our solution by adding a proxy also on the
server side. Such a proxy might be able to pre-fetch data from the server,
or perform various optimizations such as data compression. This is left for
future work.
Finally, our solution required manual investigation of the CIFS imple-
mentation and was tailored for it. A more ambitious goal would be to create
a generic protocol acceleration engine, which could automatically learn how
to accelerate a given protocol from its specification. The input to such an
acceleration engine could be a grammar of the protocol with a corresponding
40
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
state machine, and the output would be an acceleration proxy.
41
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
Bibliography
[1] Cifs technical reference. Technical report, SNIA, The
Storage Networking Industry Association CIFS Reference,
http://www.snia.org/.
[2] F5 WANJet CIFS Acceleration.
http://www.f5.com/products/wanjet/.
[3] jCIFS, Open Source implementation of SMB for Linux/Unix in
Java. http://jcifs.samba.org/.
[4] Network protocol analyzer. http://www.wireshark.org/.
[5] SAMBA, Open Source implementation of SMB for Linux/Unix in
C. http://www.samba.org/.
[6] Silver Peak NX, Accelerating Microsoft File Services (CIFS).
http://www.silver-peak.com/Solutions/Centralization/cifs.htm.
[7] SkyX, Accelerating WAN Applications.
http://www.packeteer.com.
[8] Juniper, Improving File Access Across the WAN.
http://www.juniper.net, 2005.
[9] Comtech EF Data, A Method for Accelerating File Transfer over
Satellite Links. http://www.comtechefdata.com, October 2004.
[10] Marashi Ali and Klinker James Eric. System and method for ap-
plication acceleration on a distributed computer network, Novem-
ber 2009. United States Patent Application 20090292824.
42
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
[11] Mark Allman. Improving tcp performance over satellite channels.
Master’s thesis, Ohio University, June 1997.
[12] Jacqueline Farrell Dick Buttlar and Bradford Nichols. PThreads
Programming, A POSIX Standard for Better Multiprocessing.
O’Reilly Media, September 1996.
[13] Nasir Ghani and Nokia Research Center Sudhir Dixit. Tcp/ip
enhancements for satellite networks. IEEE Communication Mag-
azine, pages 64–72, July 1999.
[14] Christopher R. Hertel. Implementing CIFS: The Common Inter-
net FileSystem. Prentice Hall, August 2003.
[15] Robin Layland. Networks need a new application delivery ar-
chitecture. BUSINESS COMMUNICATIONS REVIEW, pages
24–29, APRIL 2006.
[16] Shu Lin and Daniel J. Costello. Error Control Coding: Funda-
mentals and Applications. Prentice Hall, second edition, 1983.
[17] Craig Partridge and BBN Technologies Timothy J. Shepard.
Tcp/ip performance over satellite links. IEEE Network, pages
44–49, September/October 1997.
[18] Neil T. Spring and David Wetherall. A protocol-independent tech-
nique for eliminating redundant network traffic. ACM SIGCOMM
Computer Communication Review, 30:87–95, October 2000.
[19] Mccanne Steven and Demmer Michael J. Transaction accelerator
for client-server communication systems, December 2008. United
states Patent 7120666.
[20] Dirk-Jan van Helmond and Marc Smeets. Benefits and tradeoffs
of application-specific wan acceleration in different bandwidth,
latency and loss scenarios. research report for rp2. Master’s thesis,
University of Amsterdam, July 2006.
43
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
iii
זבזני מבחינה זו כך שהלקוח בחלונות הוא מאוד ב CIFSהבעלים של הקובץ וכו, מימוש נוצר, מי
נתונים ואפשר לשלוף הרבה נתונים המבקש כל נתון בנפרד למרות שקיימת שאילתה שמכילה את רוב
בשאילתה וגישה מרוחקת אחת לשרת ולחסוך הרבה גישות מיותרות לשרת. ישנם מספר תשובות
ות מסוג זה אפשר שנועדות רק להחזיר אינדקציה על הצלחת הפעולה, ולכן תשוב CIFSמהשרת ב
להחזיר מקומית ובמקביל לשלוח את הבקשה לשרת ולחכות לתשובה מהשרת, מנגנון זה מצריך
זהירות וטבלת תרגום מערכים מקומים ולערכים אמיתיים מהשרת.
PROXYועל הפיתרון מבוסס ה CIFSבעבודה זו אנו מדווחים על הניתוח שלנו לפרוטוקול
ח ביוצעים.שפיתחנו, כמו כן הערכת ניתו
עד לרמת ה CIFSהפיתרון שאנו מציעים הוא לא פולשני ללקוחות שמיטיב עם זמני ביצוע פקודות
ל ואינו דורש שטח אחסון כשלהי או שימוש במטמון. הפיתרון שלנו הוא ק TCPבלי האצת 50%
.VSATניתן בקלות להתאימו לטכנולוגיה הקיימת ב רב, מכאן
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
ii
שההאצה תבוא , כי נדרש קובץ גדול בכדי בלבד יכולה לתרום כשמדובר בהעברה של קבצים גדולים
נמצא ברמת CIFSחוסר היעילות ב אךפרוטוקול, חלון השליחה של הבהגדלת , למשל לידי ביטוי
הפרוטוקול הבסיסי ומשפיע גם על דפדוף בתיקיות ופתיחת קבצים. בפקודות מסוג זה מנגנוני
אינן צוואר בקבוק בביצועים. באשר לטכניקות -בקרת הגודש ובקרת הזרימה - TCPפרוטוקול ה
ת, כמות מקום האחסון הזמינה מוגבלת בצד הלקוח בתיבת שמשתמשות במטמון, בשל אילוצי עלו
כמות את ואין מספיק מקום לאחסון ), VSATקישור הלוויני (שידועה בעיקר כ של התקשורת
. יתר על כן, בהינתן העלות של התקשורת הלווינית, העלות לשמירת המטמון הנתונים הרבה הנדרשת
ת שדורשת העברת כמות נתונים לא מבוטלת היא בצד הלקוח מסונכרן עם מערכת הקבצים בצד השר
גבוהה.
שינטרל את השפעת CIFSהבעבודה זו היא למצוא מגנון האצה לפרוטוקול ופיכך המטרה שלנל
). עם WANההתנהגות הפטפטנית של הפרוטוקול מעל הקישור הלוויני (או בכלל, מעל כל רשת
בצד במובן שזה לא אמור לדרוש התקנה כלשהי המנגנון צריך להיות בלתי פולשני, עת, הזאת, באותו
או בצד השרת. הלקוח
צד בלקוח, ב VSATדרך מכשיר ה הפתרון שלנו מבוסס על האבחנה שכל התקשורת הלווינית עוברת
. בפתרון המתואר ה VSATנמצא ב PROXY, שבו ה PROXYלפיכך אנו מחפשים פתרון מבוסס
PROXY בעצם מפצל את ההתקשרות שבין הלקוח ומרכז הנתונים לשתי התקשרויות, ובמידת
צריך לממש את המנגון PROXYובות מקומיות ללקוחות. עם זאת, ההאפשר, מנסה לספק תש
בזהירות על מנת לשמור על נכונות סימנטית ביחס למערכת הקבצים.
ים לפעול בלי שום שינוי בפרוטוקול. שקוף ללקוח והן לשרת והלקוח כך שהם ממשיכ PROXYה
לא מוסיף תעבורה לרשת מהנדרש לביצוע פקודת הלקוח ואפילו במקרים מצמצם PROXYבנוסף ה
ע"י כך שהוא מקטין את מספר PROXYאת כמות התעבורה בהשוואה להרצה של אותה פקודה ללא
הגישות לשרת.
והשרת, ובעזרת מכונת מצבים זו יכול נעזר במכונת מצבים לניהול המצב בין הלקוח PROXYה
לנבא איזה פקודה הלקוח מנסה לבצע ולבקש נתונים מהשרת עוד לפני שהלקוח ביקש. בנוסף,
מתי מגדיר שאילתות שבעזרתן אפשר לשלוף נתונים על הקובץ כגון מתי הקובץ, CIFSפרוטוקול
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
i
תקציר המחקר
בשנים האחרונות אנו עדים למעבר הולך וגדל ממחשוב עצמאי למחשוב מבוסס מרכזי נתונים.
במחשוב מבוסס מרכזי נתונים, הנותנים מאוחסנים במרכז נתונים ונגישים דרך לקוחות על גבי רשת
פס הרוחב שיפור . המוטיבציה לתופעה זאת היא הפחתת עלויות,WANל גבי רשתות עהאינטרנט או
מצד אחד, ושיפור האבטחה והשימושיות וניהול הנתונים במרכזי הנתונים ר האמינות ברשתושיפו
ואת התוספת מצד שני. בגישה זו, יש צורך להפוך את ביצועי המערכת שמתקבלים לחלקים ומהירים
השהיהבדיין אפשר להבחין למרות השיפור אבל ע. עבור הניהול לבלתי מורגשת ככל האפשר
אינטרנט עדיין איטי יותר בסדרי גודל ב הלוך מהלקוח לשרת וחזור מהשרת ללקוח זמןהבאינטרנט,
מאשר ברשתות מקומיות. יתר על כן, בהרבה מקומות במדינות מפותחות, כמן גם באיזורים נידחים
כפריים בצפון אמריקה, הקשר היחיד הזמין לאינטרנט הוא דרך קישור לוויני, אשר מטבעו מוסיף
. כתוצאה מכך, על מנת להתאים רשתות אלה, מערכות קבצים מבוזורת בכל כיווןמילישניות 250
הוא CIFS ; CIFS. בעבודה זו אנו מתמקדים בפרוטוקול והז כההארו ההשהיהחייבות להסתיר את
הקבצים המבוזרת של מערכת ההפעלה חלונות של מייקרוסופט, ולכן מערכת הבסיסי שלהפרוטוקול
מבוסס על פרוטוקול התקשורת CIFSהמבוזרת הנפוצה ביותר בימינו. מערכת הקבציםגם היא
SMB שפותח בשנות השמונים המוקדמות ולכן קיימים אלמנטים רבים בפרוטוקול שמותאמים
ה מרוחקת ישמהווה פרוטוקול ג CIFSלארכקטיקטורות המחשוב שהיו קיימת דאז ואינה קיימת כיום.
ן, הוא משמש כפרוטוקול הבסיס לצרכים שונים ברמת מערכת ככמו לקבצים על פי מודל לקוח ושרת.
ההפעלה כגון שירותי הדפסה ברשת, שירותי מיקום משאבים, ניהול מרחוק למשאבי הרשת והקמת
, גילינו כי המימוש של הפרוטוקול בחלונות כולל חוסר CIFSלאחר בחינת פרוטוקל שירותי אבטחה.
כפולות רבות הפעלות סינכרוניות בה זו. חוסר היעילות מתבטא יעילות רבה, כמפורט בהמשך עבוד
במערכות הפעלה אחרות CIFSקיימים מימושים ל . בין הלקוח לשרת בביצוע של פקודות מהלקוח
.LINUXו UNIXכמו
ישנם מספר טכניקות נפוצות להאצה של מערכות קצבים מבוזרות, בין היתר יש האצות ברמת
ות במטמון בצד בלקוח בצורה נרחבת. עם זאת, שישנם גם האצות שמשתמ ),TCPפרוטוקול הרשת (
בלבד אמנם TCPמשלל סיבות: האצה של פרוטוקול ה טכניקות אלה אינן מספיקות עבור היעוד שלנו
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
.המחקר נעשה בהנחיית פרופ' רועי פרידמן בפקולטה למדעי המחשב
פרידמן על התקופה המהנה י להודות למנחה שלי, פרופ' רועי ברצונועל הדרך שעברנו במשך ההשתלמות, תודה על הסיוע, והמאתגרת ועל העזרה המקצועית והאישית. ההדרכה
תמיכתם הכספית הנדיבה של הטכניון ושל משרד המדע, המסחר והעבודה תחת פרוייקט ניצן מאוד מוערכת.
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012
מעל רשתות לוויניות CIFSהאצה של פרוטוקול
חיבור על מחקר
מגיסטר לשם מילוי חלקי של הדרישות לקבלת התואר למדעים במדעי המחשב
מוחמד מגאדלה
מכון טכנולוגי לישראל –הוגש לסנט הטכניון
2012 ינואר חיפה ב"עתש טבת
Technion - Computer Science Department - M.Sc. Thesis MSC-2012-06 - 2012