Đang Thực Hiện

perl application

I require 2 perl scripts to implement a very basic file share application to be run on our unix server.

basically 1 script for the client and 1 script to act as the server. This program does NOT have to handle multiple incomming requests (ie forking).

functionality is quite basic.

(i) The client can request only 3 services from the server. LIST, GET ,TEST.

The List command just gets all the files in 1 directory, the Get command retrieves only 1 file from that directory, the test command just tests to see if the server script is listening.

This is required quite urgently: below is the detailed requirements for 2 scripts :

a)FileShare Client Interface:

Write a perl script called [url removed, login to view] which will be the user interface to the

FileShare client. The client perl script will have the following features.

(1) It implements the following command line syntax

[url removed, login to view] [-u USERNAME [-p PASSWORD]] -s HOST:PORT test

[url removed, login to view] [-u USERNAME [-p PASSWORD]] -s HOST:PORT list

[url removed, login to view] [-u USERNAME [-p PASSWORD]] -s HOST:PORT get REMOTE_FILE [LOCAL_FILE]

For example, if we have a user 'joe' with password 'bloggs' and our host

and port is server1 and 5123 and we want to list the available files:

[url removed, login to view] -u joe -p bloggs -s server1:5123 list

(2) When given the -h option, prints the command line syntax plus the

following help message

REMOTE_FILE the name of remote file to download

LOCAL_FILE local filename to save as (optional)

-u USERNAME username (optional)

-p PASSWORD password (optional, requires -u)

-s HOST:PORT FileShare server in HOST:PORT format

-h prints this help message

(3) If the optional parameters (-u and -p) are not provided the user will be

prompted to provide them.

Note: because the -p option requires -u the user cannot provide a

password only.

For example if no username is provided, the program should prompt the

user with the following text:

Username:

Followed by

Password:

If the username has been provided but no password, the program should

prompt the user with the following text:

Password:

(4) command is one of 'test', 'list' or 'get'

test command

The test command is to aid in marking but should also aid in debugging

your programs. It will make a connection to the FileShare server and

after the authentication handshake has been completed print to

STDOUT:

FileShare authentication OK

OR

FileShare authentication FAILED

Depending on the response from the server.

list command

The list command will print to STDOUT a listing of the remote shared

directory in ASCII order, for one level only, not recursive. The listing

will not include the current or parent directory (e.g. '.' and '..'). Sub

directories will be identifiable as directories by appending a '/' suffix to

the directory name.

Given the following shared directory on the server side:

share/

|

|[url removed, login to view]

|-asubdir/

|[url removed, login to view]

|[url removed, login to view]

The command

[url removed, login to view] -u joe -p bloggs -s server1:5123 list

would print the following output

[url removed, login to view]

asubdir/

[url removed, login to view]

[url removed, login to view]

get command

The get command downloads a file from the remote server and saves it

locally. The command must support the following syntax

get REMOTE_FILE [LOCAL_FILE]

For example:

[url removed, login to view] -u joe -p bloggs -s server1:5123 get [url removed, login to view]

[url removed, login to view]

REMOTE_FILE must match an available file (i.e. as indicated by the

list output)

LOCAL_FILE is optional and allows the file to be renamed when

saved locally. By default the file will be saved to the current working

directory with the same name as the remote file

(5) If the client request fails in some manner e.g. bad user name or

password, a human readable error message should be printed to

STDERR. For example the above error could be indicated like this:

Authentication failed - Bad username or password

(6) The FileShare protocol is stateless and so is the client, a new connection

must be established each time a request is made (e.g. the connection to

server must not persist between requests).

(7) If an error occurs when making a request to the server the connection to

the server must be terminated and a sensible error message reported to

the user.

Your script must also comply with the following implementation guidelines:

• It uses a CPAN module for parsing command line options. e.g.

Getopt::Std or Getopt::Long

• If you are completing the optional part 2

It uses the [url removed, login to view] module (see below), to handle communication

with the server. It does not directly communicate with the server.

• If you are not completing the optional part 2.

It uses the IO::Socket::INET module to communicate with the server, e.g.

use IO::Socket::INET

(b)FileShare Server:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Your server script must also comply with the following implementation

guidelines:

• It uses the IO::Socket::INET module e.g. use IO::Socket::INET

• It uses the built in crypt function or any appropriate CPAN module for

interfacing with the password file e.g. Apache::Htpasswd,

HTTPD::UserAdmin, PWD::PwDigest

• It uses a CPAN module for parsing command line options. e.g.

Getopt::Std or Getopt::Long

• It lists and allows file transfers only from the current working

directory. (e.g. the directory the script was executed from).

Do not have any shell commands from your server

(e.g. `backticks` or system calls) these are security risks.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Write a perl script called [url removed, login to view] which will be the FileShare server. The

server will provide two services to clients: list and get in the form of a

stateless request/response protocol similar to HTTP. See the Protocol

Requirements section for more information

list request

In response to the list request, the server will return a list of files available

for download in the current directory, for one level only, not recursive. The

listing will not include the current or parent directory (e.g. '.' and '..')

get request

The server, upon receiving a get request, will return the contents of the

requested file as a binary stream.

The [url removed, login to view] perl script will have the following features.

(1) It implements the following command line syntax

[url removed, login to view] -p PORT -f PASSWORDFILE

Where PORT is the port the server will listen on and PASSWORDFILE is

the path to the htpasswd file to be used for authentication.

For example, if we want our server to listen on port 4270 using a

password file called fspasswd

[url removed, login to view] -p 4270 -f fspasswd

(2) The format for the password file will be htpasswd, using the 'crypt'

method to store passwords.

The server script will authenticate client requests using the

accounts in the password file.

Note: the Apache::Htpasswd module is not part of the perl installation

on our server. A recent version of Apache::Htpasswd has been installed at /

pub/usp/lib/perl5/Apache/Htpasswd.pm. There are a number of ways to

'use' this module in your program:

• The easiest method is to add a 'use lib' statement at the top of

your program. e.g.

use lib '/pub/usp/lib/perl5'

• you can also use the -I command line switch to add the /

pub/usp/lib/perl5 directory to the perl include path. e.g.

perl -I /pub/usp/lib/perl5 [url removed, login to view]

This means your #! line will need to include the switch also!

If in any part of the assignment you would like to use a module which is

not installed you should use the CPAN library to install it locally. (see

perldoc CPAN) . It is then your responsibility to submit the module

along with your programs and to ensure it is correctly loaded,

regardless of where the programs are executed from.

(3) When receiving an authentication request from the client (see Protocol

requirements) the server will check the username and password against

those in the password file and return the appropriate success or fail

message. On a fail the server must terminate the connection after

sending the response.

Protocol Requirements

You will need to design part of the protocol to communicate between the client and

server components of FileShare. The authentication or 'handshake' must follow the

procedure below but you may use any technique for the rest of the protocol

provided it meets the following requirements.

• Authentication (handshake)

When a socket connection is made with the server it will commence a

handshake protocol that will begin with the server sending the the following

text

FileShare Version 0.1

The client must then respond with the following authentication header

User username Pass password

Where username and password are replaced by the corresponding values

provided to the client by the user.

Finally the server will respond with a success or fail message to indicate if

the authentication was successful

Authentication SUCCESS

OR

Authentication FAIL

• Client requests

The server will support two types of request after a client has been

authenticated list and get. How your server recognises and responds to

these requests depends on your protocol

• When receiving a list request the server will return a list of files to the

client

• When receiving a get request the server will return the binary content

of the corresponding file to the client.

• If a request from the client does not follow the correct protocol the

server should send an error response and terminate the connection.

• If the client makes a get request for a file which does not exist the

server should send an error response clearly indicating this error and

terminate the connection.

• Other requirements

• the protocol is text based, i.e. no binary data is to be used in the

protocol with the exception of the file transfer (which of course will be

binary)

• The server should not die. Servers must be reliable and must continue

to function even after a protocol error. It can be a good idea for the

server to print errors to STDERR to assist in trouble shooting and

debugging but remember the client will not see this.

Execution Environment

Your programs will be required to run on the basic servers, e.g. server1.

Modules other than those included in the perl installation must be submitted

along with the perl scripts, with the exception of Apache::Htpasswd which may be

included from its location in /pub/usp/lib/perl5.

Your programs should make no assumptions about where it

will be executed from (e.g. the current working directory)

Remember that although when testing your program you will most likely be

running both client and server from the same machine this would not be the case

in practice, your client and server programs can only communicate using

sockets.

(c)FileShare Client Configuration:

The [url removed, login to view] script needs to be extended to support the use of configuration

files. The [url removed, login to view] script must support these additional features:

1. It supports the additional and optional command line option

[-c CONFIG_FILE]

Where CONFIG_FILE is the path to a FileShare client configuration file.

2. The config file will provide defaults for the username and server

(host:port) command line options. Note: This means that the server

option, -s, becomes optional when -c is specified.

[url removed, login to view] the -c option is provided on the command line the [url removed, login to view] script

will first read default options from the configuration file but will

allow these options to be overridden on the command line.

4. The format of the configuration shall be defined by your program but

should follow UNIX conventions. you

must include a sample of the configuration file named [url removed, login to view]

with the following options:

username jbloggs

server localhost:2021

4. The help message should display additional information related to this

Option

Kỹ năng: Perl

Xem thêm: perl application, write a recursive function, u.s. p.s, uses of binary, user tests, use of binary, use case types, use case module, use case include example, use case include, use case components, u.p.s. store, txt 2 jpg, the u.p.s. store, test the application, system tests, std list c, std list, std library, shared data services, server side application, return path, recursive programs, recursive program example, recursive function example

Về Bên Thuê:
( 1 nhận xét ) sydney, Australia

Mã Dự Án: #18631

Đã trao cho:

msteinke

I have coded similar for daily data backup.

$125 USD trong 7 ngày
(1 Đánh Giá)
2.2

5 freelancer đang chào giá trung bình $168 cho công việc này

evereq

I can do it! Very interesting.

$100 USD trong 5 ngày
(3 Đánh Giá)
3.9
iConsultant

Hello. I'm certified Perl programmer and also CPAN commotter. I'm ready to help you with this project. I will deliver fully tested and good commented code along with unit testing modules. Let me know if you are interes Thêm

$267 USD trong 12 ngày
(1 Đánh Giá)
1.4
sita123

Hello, I have wide area experience in open source technology like php/c++/linux/so files/Perl AND WINDOW based ASP,COM,DCOM,MTS,VB,VC++,.NET,Flash. Please forward me your mail ID so i can forward you project proposa Thêm

$200 USD trong 10 ngày
(0 Đánh Giá)
0.0
tend

I can start right now.

$150 USD trong 3 ngày
(0 Đánh Giá)
0.0