accelerating cifs over satellite networks · accelerating cifs over satellite networks research...

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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


– 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


0 50 100 150 200 2500

1000

2000

3000

4000

5000

6000

7000

link delay simulated (ms)

time(

ms)


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


0 50 100 150 200 2500

1000

2000

3000

4000

5000

6000


time(

ms)

Time of write file operation


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


0 50 100 150 200 2500

10

20

30

40

50

60


time(

min

s)

Time of simple browse operations


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


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


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


0 10 20 30 40 50 60 70 80 900

2000

4000

6000

8000

10000

12000

14000

16000

file size (KB)

time(

ms)



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


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


Figure 5.9: Read file operation with a variable file size, the relativestandard deviation in this batch was below 7.15%

37


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


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


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


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


state machine, and the output would be an acceleration proxy.

41


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


[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


iii

זבזני מבחינה זו כך שהלקוח בחלונות הוא מאוד ב CIFSהבעלים של הקובץ וכו, מימוש נוצר, מי

נתונים ואפשר לשלוף הרבה נתונים המבקש כל נתון בנפרד למרות שקיימת שאילתה שמכילה את רוב

בשאילתה וגישה מרוחקת אחת לשרת ולחסוך הרבה גישות מיותרות לשרת. ישנם מספר תשובות

ות מסוג זה אפשר שנועדות רק להחזיר אינדקציה על הצלחת הפעולה, ולכן תשוב CIFSמהשרת ב

להחזיר מקומית ובמקביל לשלוח את הבקשה לשרת ולחכות לתשובה מהשרת, מנגנון זה מצריך

זהירות וטבלת תרגום מערכים מקומים ולערכים אמיתיים מהשרת.

PROXYועל הפיתרון מבוסס ה CIFSבעבודה זו אנו מדווחים על הניתוח שלנו לפרוטוקול

ח ביוצעים.שפיתחנו, כמו כן הערכת ניתו

עד לרמת ה CIFSהפיתרון שאנו מציעים הוא לא פולשני ללקוחות שמיטיב עם זמני ביצוע פקודות

ל ואינו דורש שטח אחסון כשלהי או שימוש במטמון. הפיתרון שלנו הוא ק TCPבלי האצת 50%

.VSATניתן בקלות להתאימו לטכנולוגיה הקיימת ב רב, מכאן


ii

שההאצה תבוא , כי נדרש קובץ גדול בכדי בלבד יכולה לתרום כשמדובר בהעברה של קבצים גדולים

נמצא ברמת CIFSחוסר היעילות ב אךפרוטוקול, חלון השליחה של הבהגדלת , למשל לידי ביטוי

הפרוטוקול הבסיסי ומשפיע גם על דפדוף בתיקיות ופתיחת קבצים. בפקודות מסוג זה מנגנוני

אינן צוואר בקבוק בביצועים. באשר לטכניקות -בקרת הגודש ובקרת הזרימה - TCPפרוטוקול ה

ת, כמות מקום האחסון הזמינה מוגבלת בצד הלקוח בתיבת שמשתמשות במטמון, בשל אילוצי עלו

כמות את ואין מספיק מקום לאחסון ), VSATקישור הלוויני (שידועה בעיקר כ של התקשורת

. יתר על כן, בהינתן העלות של התקשורת הלווינית, העלות לשמירת המטמון הנתונים הרבה הנדרשת

ת שדורשת העברת כמות נתונים לא מבוטלת היא בצד הלקוח מסונכרן עם מערכת הקבצים בצד השר

גבוהה.

שינטרל את השפעת CIFSהבעבודה זו היא למצוא מגנון האצה לפרוטוקול ופיכך המטרה שלנל

). עם WANההתנהגות הפטפטנית של הפרוטוקול מעל הקישור הלוויני (או בכלל, מעל כל רשת

בצד במובן שזה לא אמור לדרוש התקנה כלשהי המנגנון צריך להיות בלתי פולשני, עת, הזאת, באותו

או בצד השרת. הלקוח

צד בלקוח, ב VSATדרך מכשיר ה הפתרון שלנו מבוסס על האבחנה שכל התקשורת הלווינית עוברת

. בפתרון המתואר ה VSATנמצא ב PROXY, שבו ה PROXYלפיכך אנו מחפשים פתרון מבוסס

PROXY בעצם מפצל את ההתקשרות שבין הלקוח ומרכז הנתונים לשתי התקשרויות, ובמידת

צריך לממש את המנגון PROXYובות מקומיות ללקוחות. עם זאת, ההאפשר, מנסה לספק תש

בזהירות על מנת לשמור על נכונות סימנטית ביחס למערכת הקבצים.

ים לפעול בלי שום שינוי בפרוטוקול. שקוף ללקוח והן לשרת והלקוח כך שהם ממשיכ PROXYה

לא מוסיף תעבורה לרשת מהנדרש לביצוע פקודת הלקוח ואפילו במקרים מצמצם PROXYבנוסף ה

ע"י כך שהוא מקטין את מספר PROXYאת כמות התעבורה בהשוואה להרצה של אותה פקודה ללא

הגישות לשרת.

והשרת, ובעזרת מכונת מצבים זו יכול נעזר במכונת מצבים לניהול המצב בין הלקוח PROXYה

לנבא איזה פקודה הלקוח מנסה לבצע ולבקש נתונים מהשרת עוד לפני שהלקוח ביקש. בנוסף,

מתי מגדיר שאילתות שבעזרתן אפשר לשלוף נתונים על הקובץ כגון מתי הקובץ, CIFSפרוטוקול


i

תקציר המחקר

בשנים האחרונות אנו עדים למעבר הולך וגדל ממחשוב עצמאי למחשוב מבוסס מרכזי נתונים.

במחשוב מבוסס מרכזי נתונים, הנותנים מאוחסנים במרכז נתונים ונגישים דרך לקוחות על גבי רשת

פס הרוחב שיפור . המוטיבציה לתופעה זאת היא הפחתת עלויות,WANל גבי רשתות עהאינטרנט או

מצד אחד, ושיפור האבטחה והשימושיות וניהול הנתונים במרכזי הנתונים ר האמינות ברשתושיפו

ואת התוספת מצד שני. בגישה זו, יש צורך להפוך את ביצועי המערכת שמתקבלים לחלקים ומהירים

השהיהבדיין אפשר להבחין למרות השיפור אבל ע. עבור הניהול לבלתי מורגשת ככל האפשר

אינטרנט עדיין איטי יותר בסדרי גודל ב הלוך מהלקוח לשרת וחזור מהשרת ללקוח זמןהבאינטרנט,

מאשר ברשתות מקומיות. יתר על כן, בהרבה מקומות במדינות מפותחות, כמן גם באיזורים נידחים

כפריים בצפון אמריקה, הקשר היחיד הזמין לאינטרנט הוא דרך קישור לוויני, אשר מטבעו מוסיף

. כתוצאה מכך, על מנת להתאים רשתות אלה, מערכות קבצים מבוזורת בכל כיווןמילישניות 250

הוא CIFS ; CIFS. בעבודה זו אנו מתמקדים בפרוטוקול והז כההארו ההשהיהחייבות להסתיר את

הקבצים המבוזרת של מערכת ההפעלה חלונות של מייקרוסופט, ולכן מערכת הבסיסי שלהפרוטוקול

מבוסס על פרוטוקול התקשורת CIFSהמבוזרת הנפוצה ביותר בימינו. מערכת הקבציםגם היא

SMB שפותח בשנות השמונים המוקדמות ולכן קיימים אלמנטים רבים בפרוטוקול שמותאמים

ה מרוחקת ישמהווה פרוטוקול ג CIFSלארכקטיקטורות המחשוב שהיו קיימת דאז ואינה קיימת כיום.

ן, הוא משמש כפרוטוקול הבסיס לצרכים שונים ברמת מערכת ככמו לקבצים על פי מודל לקוח ושרת.

ההפעלה כגון שירותי הדפסה ברשת, שירותי מיקום משאבים, ניהול מרחוק למשאבי הרשת והקמת

, גילינו כי המימוש של הפרוטוקול בחלונות כולל חוסר CIFSלאחר בחינת פרוטוקל שירותי אבטחה.

כפולות רבות הפעלות סינכרוניות בה זו. חוסר היעילות מתבטא יעילות רבה, כמפורט בהמשך עבוד

במערכות הפעלה אחרות CIFSקיימים מימושים ל . בין הלקוח לשרת בביצוע של פקודות מהלקוח

.LINUXו UNIXכמו

ישנם מספר טכניקות נפוצות להאצה של מערכות קצבים מבוזרות, בין היתר יש האצות ברמת

ות במטמון בצד בלקוח בצורה נרחבת. עם זאת, שישנם גם האצות שמשתמ ),TCPפרוטוקול הרשת (

בלבד אמנם TCPמשלל סיבות: האצה של פרוטוקול ה טכניקות אלה אינן מספיקות עבור היעוד שלנו


.המחקר נעשה בהנחיית פרופ' רועי פרידמן בפקולטה למדעי המחשב

פרידמן על התקופה המהנה י להודות למנחה שלי, פרופ' רועי ברצונועל הדרך שעברנו במשך ההשתלמות, תודה על הסיוע, והמאתגרת ועל העזרה המקצועית והאישית. ההדרכה

תמיכתם הכספית הנדיבה של הטכניון ושל משרד המדע, המסחר והעבודה תחת פרוייקט ניצן מאוד מוערכת.


מעל רשתות לוויניות CIFSהאצה של פרוטוקול

חיבור על מחקר

מגיסטר לשם מילוי חלקי של הדרישות לקבלת התואר למדעים במדעי המחשב

מוחמד מגאדלה

מכון טכנולוגי לישראל –הוגש לסנט הטכניון

2012 ינואר חיפה ב"עתש טבת


CIFSהאצה של פרוטוקול מעל רשתות לוויניות

מוחמד מגאדלה


accelerating cifs over satellite networks · accelerating cifs over satellite networks research...

Documents