DAILY NEWS AND INFORMATION FOR THE GLOBAL GRID COMMUNITY /    ( Table of Contents )

Special Features:

DEFINING A CONCEPT FOR REMOTE NETWORK FILE SYSTEM SERVICES
By K.S.Venkatram

This article has been prefaced for mutual sharing. My focus and motto is that today, the limited interest in network specification and related results are from remaining with such based interest. Any incomplete specification drives the plan by incomplete design or more effort. To reduce such makeshift alignment or incomplete design, this article introduces scope for extending the effectiveness.

Today, the file system services are losing interoperability and experience concepts due to such limited focus and associations of working with remote, temporary or incremental versions. We all know that working with temporary or incremental versions remain existing network specification, but designing a new model is a network solution or specification.

This article proposes a new architectural concept and does not limit scope to existing network solutions or specifications.

Concept publications and existing analysis:

• Development plans, interoperability and extensibility from this article is published as part of the series about "Defining a concept for a Smart Neighborhood" in the Grid Today. The article is not a published solution. Rather, they introduce the reader to a concept for a smarter neighborhood and guide the user through a comparative analysis and extensibility of a sensor-controlled network in enterprise scenarios.
• In this article I propose to guide the extensible network experience with the help of this smarter architecture and neighborhood. The model will support this extensible experience from concepts for reading or accessing remote file system support.
• When working with a server blade (for me this is a high-expectation and performance-enabled server), I did as usual connect from a local machine to the server blade using a mapped drive. With this mapped drive I attempted accessing remote files on the server blade.

Step One:

• I attempted to copy a remote file from the server blade onto the local machines hard drive. In this intent I first clicked on the "Windows Explorer>Edit>Copy menu command" after selecting the network file on the server blade.

Step Two:

• With the copy command execution done, I simulated a remote file system failure by disconnecting the "mapped drive connection" to this server blade.

Step Three:

• After disconnecting the mapped drive, I then executed the remaining command "the Windows Explorer>Edit>Paste" for copying the network file. Dependencies on the mapped drive caused this copy operation to fail.

Step Three Presumption:

• In this copy failure, the "Windows Explorer" inconsistently displayed that it could not complete the copy. According to me this presumption is not effective architecture. I had executed actions known to every user i.e. first mapped a drive to the remote file system on this server blade, next selected a file and then continued my work.
• In this copy failure, what I did was disconnect the mapped drive; for me I simulated a network failure with this staged action. After a network failure I expected to place the remote file system on my local machine. As the mapped drive experience today does not extend to support "intelligent actions of accessing remote files with decision principles." The remote file system's instant availability is the only expectation. The "Windows Explorer>Edit>Commands" have many naming presumptions and incomplete settings. These presumptions do not extend support for users clicking on them while accessing network file systems.

The Model And Basis

Presuming this copy was intended some time interval back, the Edit>Copy command did not enable the completion of the copy operation, when the Edit>Paste command was executed some actions later. The file copy should succeed later like any other "copy-paste" operation.

To set the context for the model service, we review "copy-paste" operations for many content-based and memory-based buffers.

I could say commonly we use this "copy-paste" operation to replicate information by working with buffers; we typically copy some buffer and then place the memory images into different contexts to replicate content. Today this is effective and complete, such that when we intend to copy and paste memory buffers for information, across time intervals and different initiatives the content is persisted.

For any reader, the Windows platform supports retaining the "in memory images, memory buffers" even if the source for this information is not operational on the local machine. Like we could open document A, execute a copy of information, close document A, proceed to open document B and paste this copy of information, this means that though document A is still not open the copy of content is persisted. Like we could interact with application A, execute a copy of information from this application A, close application A, proceed to execute application B and paste this copy of information, this means that though application A is still not open the copy of content is persisted to permit application B to use this information.

Model Service And Support

Aligning with network administration fact, the file was copied from a remote file system server. The Windows Explorer and the mapped connection services should have extended support to safely complete such intent.

Reviewing this support for a remote file system resource, a remote file copy is today initiated like any "Windows Explorer>Edit>Copy," as the actions are comparable to the application A example, the concept is that the paste of the remote file could be completed much later without the unplanned assumptions; For many interests the initial file copy should work independent of the status of the remote file system.

For any interest this conceptually translates as extensive effectiveness, here effectiveness is that if the "Windows Explorer>Edit>Copy" command is executed then the completion of the file copy, access should not be affected when the remote file system suddenly drops connections.

For any reader interested in the Windows Platform support, this means whenever a "Windows Explorer>Edit>Copy" command succeeds smart decisions should enable the client to retain the file image intelligently irrespective of any remote file system connection error or network down derivative.

We know that as intelligent capture of remote file system commands are not operational, the practical failures in completing a file copy are very significant and pertinent.

Model Service And Support Using New Remote Copy Options

For understanding this context, extending remote file system commands using smart decisions scopes a smarter solution. The step to planning for a smarter solution is achievable by proposing an idea to plug-in into the network connectivity or enhance the remote file access commands for copying and accessing remote files.

For any reader interested in Windows platforms, this means the existing "Windows Explorer>Edit>Copy" command is easily extendable. We could support a concept of a "Windows Explorer>Edit>Remote Copy" command.

The extensible Remote Copy command will conceive remote file access-copy solutions and subsequently address a wide scope of network software resources. The work in effect is to enable smarter remote access or extend some features to address any remote file system connection error or network down derivative.

The remote file system access supported by a decision model expects to address network failures, hard disk failures while executing a remote file copy.

We replace limited support for a remote file copy by intent-aided support. Today a network user selects a remote file to copy and expects that this action will ensure a copy without concerns for the network failure or disk failure or free space limitations that easily cause this copy to fail.

This means that the network user could experience many new intent-aided features. The usual action of selecting a remote file, initiating a file copy by clicking on the Edit>Copy option could be extended to capturing the file or file image as a decision and then retaining this reference till the network user clicks on Edit>Paste option.

This concept will ensure that the file copy commits, the user will expect to execute the initial "Remote Copy accompanied by an extension to verify Disk Space," if this option completes the user can safely assume that the remote access is supported. The support means that even if network connections are affected by packet drop errors or sudden traffic errors or network access errors or any other file system error, the initial success of the "Remote Copy with Disk Space Verification" ensures a committed result.

For any referral, this decision model works intents for many forms of files like remote or temporary or incremental versions. Again it is not the same as expecting any file transfer application or windows application stepping through data using temporary or incremental versions.

Smart Decision Support For Remote Services

To understand the "Smart Decision Support" model and idea, we first review usage of certain features that are commonly interfaced with in file system usage.

• Current Mapped Drive solutions help the network user execute remote actions with a file system. These solutions need a "Smart Decision Support" service for a mapped drive.
• The "Smart Decision Support" service could then ensure that any remote action using specific mapped access is captured. Capturing Remote File System updates and edits, ensures that file usage is supported by intelligent restoration. Thus the network user is confident of experiencing successful results and pertinent file system experiences. The "Smart Decision Support for extensible Remote file access" would then conform to extensible industry standards expected by any network experience.
• This shared, for efficient administration the "Extensible access to Remote File Systems," the "Smart Decision Support Model" idea plans and tracks the Remote Actions for any user interested in a Remote File System Resource or Application.

To understand the "Smart Decision Support" concept, extensible experience we review the extensible file system support possible:

The concept does strategize settings and develops a solution that extends the mapped connection actions from simple incomplete solutions or solutions that may fail due to many possible errors to actions that are more intelligent. The intelligent file system service will have a Decision Support and Fail-Safe model integrated for accessing remote files.

In developing this network outlook and products for a smart connectivity experience, network clients and network interfaces can easily realize this kind of management with the proposed "Smart Decision Support" idea.

The concept sets an objective that if a user executes certain actions on a Remote File System with intent to edit or integrate results, then the "Smart Decision Support Model" will by decision-commit-options remember the edit actions. These decision-commit actions either commit the remote edit action despite network connectivity errors or retain captured indicators for the edit operation to succeed on the next network interaction.

What exactly is the Remote-File-System-Access-Decision Model and how do I use it?

Today interoperability is core for any network connectivity solution. The Remote-File-System-Access-Decision Model bases it's specification on the principal of using network connectivity to access or use remote files, storage and remote services.

The introduction and development scope for the Remote-File-System-Access-Decision Model is that the model proposes integrating and supporting the following services to support the new mechanisms of remote file system access:

• Interfaces, Basic services
• Neighborhood Assistant Interfaces invoked by specific Platforms
• Interfaces invoked by specific Platform connectivity services
• Interfaces invoked by specific Platform File System services
• Interfaces invoked by specific Explorer infrastructure services
• Interfaces invoked by specific Marshalling services to write/read/align with various file formats, images
• Interfaces to manage using virtual folders explicitly created for the Neighborhood Assistant Decision Support and Information services.

What exactly is meant by Remote-File-System-Access-Decision services and how do I use it?

The Remote File System Access Services and Interfaces proposes services and concepts that can be used to write, read, report and manage the new virtual folders explicitly created for the Assistant enabled connectivity decisions and neighborhood Remote File System Information services. These Services propose to model a grammatical set of rules to enable the network user experience a new architectural Smart Neighborhood Assistant feature that smartens the manageability and effectiveness while administering remote file system access.

What exactly is extended by Smart Neighborhood Assistant services and how do I use it?

We review the recommendation for Extensible Access to Remote File Systems; the concept proposes to introduce the unique feature of a "Smart Neighborhood Assistant" to assist, enable smart decision support and manages remote file system access in effective ways. This Smart Neighborhood Assistant will be designed with the components that help remember and realize remote File System access.

To describe the Smart Neighborhood Assistant in specification, it can be developed through components that interface with the client services, shell/explorer services, and relevant marshalling services and manage the smart file access support through assistant-neighborhood infrastructure.

We could term the first component of the Smart Neighborhood Assistant as "NetworkServerSensorServices," this component interfaces with the host, remote server and supported remote file systems to enable services.

We could term the second component of the Smart Neighborhood Assistant as "PlugNPlaySensorServices," this component interfaces with the host, remote server and remote file system to enable services. The term PlugNPlay is like the scenarios today where the services of any new hardware, driver, service can be managed and relied on without any explicit functionality enhancement in the infrastructure running the new services.

Similar extensible connectivity that any network user could effectively rely on is proposed by the "PlugNPlaySensorServices" dynamic administration specification. The "PlugNPlaySensorServices" for a particular platform will first expect the "NetworkServerSensorServices" to resolve initial requirements, when the defined set of requirements are initially enabled, any new remote server, new remote file systems can be supported by describing the new remote server or new remote file system information in a grammatical, extensible simple model.

We could term the third component of the Smart Neighborhood Assistant as "InterceptionSensorServices," this component interfaces with the host, remote server and remote file system by intercepting file access using the decision model functionality and procedures to manage and enable proposed assistance in connectivity.

We could term the fourth component of the Smart Neighborhood Assistant as "PlugNPlayServices," this component interfaces with the host, remote server and remote file system by reading the grammatical extensible model that describes functionality and procedures to enable extensible connectivity.

About The Author

K.S.Venkatram is a Computer Engineer from the University Of Poona in India. He has a Microsoft Certified Professional certificate in Windows 2000 Networking Infrastructure.