Курсов проект № 1 по “Интернет програмиране с Java”

Проект 1.1 – UDP Chat Client/Server:

Да се напишe клиент/сървър приложение на Java, което използвайки възможностите на пакета java.net дава възможност за комуникация между много потребители в локална мрежа. Изпращането и приемането на съобщения трябва да бъде реализирано с UDP сокети. Трябва да се напишат 2 програми – UDP Chat сървър и UDP Chat клиент. UDP Chat сървърът трябва да служи като централизирана точка, през която минават съобщенията, които са предназначени за всички потребители. UDP Chat клиентът трябва да е клиентско приложение, което си комуникира със UDP Chat сървъра и другите UDP Chat клиенти чрез UDP пакети.

UDP Chat клиентът представлява програма, която приема потребителски команди и ги изпълнява и същевременно приема изпратени до нея съобщения и ги отпечатва. Всеки потребител трябва да може да изпраща съобщения до всички останали или до конкретен друг потребител. Получаването и изпращането на съобщения трябва да става по UDP на порт 2002. Трябва да се реализират следните команди:

SEND IP_ADDRESS MESSAGE – за изпращане на съобщение до конкретен потребител. Съобщението се изпраща чрез UDP пакет директно до зададения IP адрес на порт 2002 (не минава през сървъра).

SEND * MESSAGE – за изпращане на съобщение до всички потребители. Тази команда, без изменение се изпраща чрез UDP пакет до UDP Chat сървъра на порт 2002. IP адресът на UDP Chat сървъра е предварително зададен като константа в клиентското приложение.

QUIT – за изход от клиентската програма

При пристигане на съобщение от някой потребител то трябва да се извежда по подходящ начин. При стартиране на клиента той трябва да изпраща до UDP Chat сървъра команда “REGISTER ”, с което го уведомява, че се е включил в Chat-а. При изход, клиентът трябва да изпраща друга команда “UNREGISTER ” до UDP Chat сървъра, за да го уведоми, че е излязъл от Chat-a. Във всеки един момент потребителят трябва да има възможност да изпълнява произволна от изброените по-горе команди.

UDP Chat сървърът представлява програма, която слуша на UDP порт 2002, приема команди и да ги изпълнява по подходящ начин. Командите са следните:

REGISTER – добавя IP адреса в списъка от клиентите (ако го няма вече там)

UNREGISTER – премахва IP адреса от списъка от клиентите (ако го има там)

SEND * MESSAGE – изпраща зададеното съобщение до всички клиенти чрез UDP пакет на порт 2002, като включва в него и IP адреса на изпращача, т.е. на този, от когото е получено, за да знае клиентът кой го е изпратил първоначално.

При пристигане на друга команда, тя се игнорира. UPD Chat сървърът трябва да поддържа списък от IP адресите на клиентите си, като при стартиране този списък е празен. Сървърът трябва да може да изпълнява много команди от различни потребители, дори ако са изпратени едновременно.

Пример: Нека UDP Chat сървърът е стартиран на адрес 192.168.0.31 и слуша на порт 2002. Alan и Bob са потребители в локална мрежа съответно с IP адреси 192.168.0.1 и 192.168.0.2. Двамата стартират вашия UDP Chat клиент. Съответно сървърът получава команди за регистрация на IP адреси 192.168.0.1 и 192.168.0.2.

Потребител Alan пише командите:

SEND * Hi all!

SEND 192.168.0.2 Hi Bob!

Първата команда се изпраща без изменение до сървъра (по UDP към 192.168.0.31:2002), а втората просто предизвиква изпращане на клиента 192.168.0.2 по UDP на порт 2002 съобщението “Hi Bob!”.

След това потребител Bob пише командите:

SEND 192.168.0.1 Hi Alan, I am pleased to chat with you!

SEND * Anybody for Counter Strike?

Те се обработва отново съгласно описанието на клиентското приложение.

След това Alan пише командите:

SEND 192.168.0.2 Bob, I don’t like this game. I have to work now.

SEND 192.168.0.2 Goodbye Bob.

SEND * Goodbye all.

QUIT

След това потребител Bob пише командите:

SEND * Ok. I am leaving. The game session will start at 11.30 pm. Bye all.

QUIT

Сървърът приема всички команди от вида “SEND * MESSAGE“ и разпраща съобщенията до всички от списъка си с клиенти, като слага в тях някаква идентификация от кого са пристигнали. При излизане от Chat-а (с командата QUIT), сървърът получава и изпълнява команди за напускане на съответните клиенти и ги изтрива от списъците.

Ако всичко е протекло нормално, екранът на Alan в този момент трябва да изглежда по начин подобен на този:

Welcome to the UDP chat

SEND * Hi all!

Received message from 192.168.0.1: Hi all!

SEND 192.168.0.2 Hi Bob!

Received message from 192.168.0.2: Hi Alan, I am pleased to chat with you!

Received message from 192.168.0.2: Anybody for Counter Strike?

SEND 192.168.0.2 Bob, I don’t like this game. I have to work now.

SEND 192.168.0.2 Goodbye Bob.

SEND * Goodbye all.

Received message from 192.168.0.1: Goodbye all.

QUIT

Екранът на Bob в този момент трябва да изглежда по начин подобен на този:

Welcome to the UDP chat

Received message from 192.168.0.1: Hi all!

Received message from 192.168.0.1: Hi Bob!

SEND 192.168.0.1 Hi Alan, I am pleased to chat with you!

SEND * Anybody for Counter Strike?

Received message from 192.168.0.2: Anybody for Counter Strike?

Received message from 192.168.0.1: Bob, I don’t like this game. I have to work now.

Received message from 192.168.0.1: Goodbye Bob.

Received message from 192.168.0.1: Goodbye all.

SEND * Ok. I am leaving. The game session will start at 11.30 pm. Bye all.

Received message from 192.168.0.2: Ok. I am leaving. The game session will start at 11.30 pm. Bye all.

QUIT

Не е нужно да създавате графичен потребителски интерфейс. Достатъчно е да напишете конзолни приложения, които реализират описаната функционалност. Не е нужно да се грижите за синхронизация на конзолата (т.е. допустимо е докато пишете команда, съобщение, пристигнало от някъде, да се отпечата върху реда, в които пишете).

Забележка: В по-старите версии на настоящия документ проект 1.1 беше друг (Multicast Chat), но се наложи да бъде променен заради необходимостта от работеща локална мрежа за да се използват Multicast сокети. Заради невъзможността на повечето от вас да разработват проекта си на компютър, който е включен в локална мрежа, се наложи условието му да бъде променено. Моля всички да работят по новото условие (UDP Chat Client/Server)!

Проект 1.2 – Simple Web Server:

Да се напише програма на Java, която използвайки възможностите на пакета java.net реализира прост Web-сървър, който обслужва TCP заявките на порт 80. Сървърът трябва да може да работи с няколко потребителя едновременно и да отговаря на следната команда:

GET [ресурс] HTTP/x.x – за извличане на файл от сървъра съгласно HTTP протокола

При заявка за достъп до директория на сървъра (например при поискване на /docs/), той трябва да връща динамично генериран HTML документ със списък от линкове към всички файлове и директории в съответната директория. При заявка за достъп до файл (например при поискване на /index.html), трябва да връща този файл. Ако файлът не съществува или не може да бъде отворен за четене, трябва да се връща грешка 404 съгласно HTTP протокола (виж примерите). Имената на ресурсите в GET-заявките могат да бъдат зададени както във вид на URL (например http://localhost/index.html), така и във вид на път и име до ресурса (например /welcome.gif). Ако името на един ресурс е зададено чрез URL, вашият сървър трябва да извлече от това URL само частта задаваща пътя и името на ресурса, като игнорира http:// частта и host-а. Вашият сървър трябва да приема за главна директория (Document root) някоя предварително фиксирана директория на от файловата система (например C:\DOCUMENT_ROOT). Тази директория e физическото съответствие във файловата система на главната виртуална директория в сървъра. Тази главна виртуална директория означаваме с “/”. В нашия пример ако потребителят поиска от сървъра файла /docs/inetjava/InetJava.doc, това съответства на физическия файл C:\DOCUMENT_ROOT\docs\inetjava\InetJava.doc, а ако поиска директорията /, това съответства на физическата директория C:\DOCUMENT_ROOT\ във файловата система на сървъра. На потребителя трябва да се дава достъп до всички файлове и поддиректории на Document root директорията и до никои други, т.е. разхождайки се по директориите, той трябва да не може да напусне главната виртуална директория.

При команда, която не е GET, да се върне отговор:

HTTP/1.0 501 Not Implemented

MIME-Version: 1.0

Content-type: text/html

Not implemented

Не е нужно да създавате графичен потребителски интерфейс. Достатъчно е да напишете конзолно приложение, което реализира описаната функционалност. Можете да тествате вашето приложение със стандартен Web-браузър (например Internet Explorer).

За улеснение може да се счита, че в имената на файловете и директориите няма интервали и специални символи (като “, ‘, :, /, \ и подобни).

Пример: Web-браузерът (клиентското приложение) се свързва на порт 80 към вашия Simple Web Server и задава няколко-редова текстова заявка. Например:

GET http://localhost/index.html HTTP/1.1

Accept: */*

Accept-Language: bg

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Host: localhost

Connection: Keep-Alive

Cache-Control: no-cache

Забележете, че последният ред на заявката е празен. Съгласно HTTP протокола този празен ред определя края на заявката. В края на първия ред е зададена версията на HTTP протокола която е използвана за формиране на заявката. Тя може да бъде както HTTP/1.1, така и HTTP/1.0. Независимо от тази версия вашият сървър трябва да връща отговорите си по протокол HTTP/1.0. Той трябва да отвори файла index.html, намиращ се в главната виртуална директория и да го върне на клиента в съответен отговор. Например:

HTTP/1.0 200 OK

MIME-Version: 1.0

Content-type: text/html

Забележете че, между заглавната част на отговора и самия документ има оставен празен ред. Съгласно HTTP протокола този празен ред разделя хедъра от данните в отговора на HTTP GET заявка.

Вашият Web-сървър трябва да задава в хедъра на отговора в полето Content-type различни стойности в зависимост от разширението на поискания файл:

text/html – за *.htm, *.html файлове

image/gif – за *.gif файлове

image/jpg – за *.jpg файлове

application/zip – за *.zip файлове

text/plain – за всички останали типове файлове (*.*)

Освен това в този хедър на HTTP отговора трябва да се включи още един ред: “MIME-Version: 1.0”, който задава с коя версия на MIME стандарта да се тълкува реда “Content type: ...”.

Пример 2:

Заявка (изпратена от клиента за извеждане на файловете от директория /nakov):

GET /nakov HTTP/1.1

Accept: */*

Host: localhost

Отговор (върнат от сървъра):

HTTP/1.0 200 OK

MIME-Version: 1.0

Content-type: text/html

Directory listing of /nakov/

/nakov/InetJava.doc

/nakov/HTTP_protocol.zip

/nakov/JAVA_sockets.zip

Вижда се, че съгласно спецификацията на вашия Web-сървър, той връща списък с линкове към файлове в зададената директория (когато тя съществува, т.е. има физическо съответствие във файловата система). Забележете, че ресурсът поискан с командата GET /nakov HTTP/1.1 е зададен не като URL, а като път и име на ресурс. Тази команда е еквивалентна на командата GET http://localhost/nakov HTTP/1.1 в рамките на вашия Web-сървър.

Пример 3:

Заявка за несъществуващ файл (изпратена от клиента):

GET http://localhost/nakov/index.html HTTP/1.1

Accept: */*

Host: localhost 

Отговор (върнат от сървъра):

HTTP/1.0 404 Not Found

MIME-Version: 1.0

Content-type: text/html

Requested document not found!

Пример 4:

Неподдържана заявка (изпратена от клиента):

POST http://localhost/nakov/index.php HTTP/1.0

Accept: */*

Отговор (върнат от сървъра):

HTTP/1.0 501 Not Implemented

MIME-Version: 1.0

Content-type: text/html

Not implemented

Проект 1.3 – Simple HTTP Proxy Server:

Да се напише програма на Java, която използвайки възможностите на пакета java.net реализира прост HTTP Proxy-сървър. Този Proxy-сървър не е нужно да е напълно работоспособен и трябва да реализира само частично действието на истинските Proxy-сървъри. Вашият сървър трябва да слуша на TCP порт 3128 и да обслужва HTTP GET заявки. Всяка HTTP GET заявка е от вида:

GET HTTP/x.y

където последнят ред е празен (съгласно HTTP протокола). Например:

GET http://localhost/nakov/index.html HTTP/1.1

Accept: */*

Host: localhost

Proxy-сървърът, който трябва да напишете трябва да анализира зададената HTTP заявка, да извлича от нея Web-сървъра, за който тя е предназначена и да заменя версията на HTTP протокола от края на първия ред (HTTP/x.y) с HTTP/1.0. Получената нова HTTP заявка трябва да се изпраща за изпълнение към вече известния web-сървър (host). Полученият резултат трябва да се върне обратно на клиента. Web-сървърът трябва да се извлича от URL-то, ако присъства в него или от полето Host в хедъра на заявката в противен случай. Ако не е зададен порт, се подразбира порт 80. Всички HTTP GET заявки се преобразуват до HTTP/1.0 GET заявки, защото протоколът HTTP/1.0 е по-прост за използване. Схемата на действие на Proxy-сървъра е следната:

Клиентите изпращат HTTP GET заявки за достъп до отдалечени обекти не конкретно към Web-сървъра, на който те трябва да бъдат изпълнени, а към Proxy-сървъра, а той ги препраща и изпълнява на съответния Web-сървър и връща резултата на клиентите. (С понятията Web-сървър и HTTP сървър означаваме едно и също нещо – сървър, обслужващ заявки по протокол HTTP). След връщането на резултата на клиента, сокетът с него се затваря. За простота се предполага, че клиентът изпраща само HTTP GET заявки (т.е. такива, чийто първи ред започва с “GET ”). POST и HEAD заявки не се поддържат, което означава, че вашият Proxy-сървър не е напълно работоспособен, но това ограничение е поставено само за улеснение на задачата. Вашият Proxy-сървър трябва да може да обслужва няколко клиента едновременно. Не е нужно да създавате графичен потребителски интерфейс. Достатъчно е да напишете конзолно приложение, което реализира описаната функционалност.

В Интернет Proxy-сървъри се използват по няколко причини: за ускоряване достъпа до често използвани ресурси чрез кеширане; за ограничаване на достъпа до някои ресурси чрез филтриране; за достъп до отдалечени ресурси от мережа, която е зад firewall. Вашият Proxy-сървър трябва да  спира достъпа до адреси в домейна “.bg”. При заявка за достъп до такъв адрес, да се връща грешка 403 – Forbidden. Вашият малък Proxy-сървър трябва да може да се използва от страндартен Web-браузър (например Internet Explorer). Той трябва да отпечатва на стандартния изход всички клиентски заявки и съответните им отговори. При заявка към сървър, който е недостъпен по някаква причина, трябва да се върне грешка 404 – Not Found, (въпреки, че това противоречи на стандарта, според който трябва да се върне грешка с друг код). Връщането на грешка става чрез отговор на заявка по HTTP протокола подобна на следната:

HTTP/1.0 404 Not Found

MIME-Version: 1.0

Content-type: text/html

Requested document not found!

където кодът на HТTP отговора е код на грешка (в случая 404).

Пример: Web-браузърът (клиентското приложение, в нашия случай Internet Explorer 6.0) се свързва на порт 3128 към вашия Simple Proxy Server и задава няколко-редова HTTP заявка. Например:

GET /index.html HTTP/1.1

Accept: */*

Accept-Language: bg

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Host: localhost

Connection: Keep-Alive

Cache-Control: no-cache

Вашият Proxy-сървър прочита клиентската заявка, променя версията на HTTP протокола (намира се на първия ред), извлича името на host-а, за който е предназначена тя, свързва се към този host (в нашия пример localhost) на порт 80 и подава преработената HTTP заявка на съответния Web-сървър. Забележете, че URL-то не съдържа host-а и той трябва да се вземе от реда “Host: localhost”. Ето и преработената заявка:

GET /index.html HTTP/1.0

Accept: */*

Accept-Language: bg

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Host: localhost

Connection: Keep-Alive

Cache-Control: no-cache

Web-сървърът, който слуша на порт 80 на локалната машина (localhost), връща в отговор на тази заявка поискания документ /index.html и затваря комуникационния сокет:

HTTP/1.1 200 OK

MIME-Version: 1.0

Content-type: text/html

Този отговор, без изменения се изпраща на клиента и сокета за комуникация с него се затвяря.

Пример 2: Web-браузърът се свързва на порт 3128 към вашия Proxy Server и задава следната HTTP заявка:

GET http://www.top.bg/ HTTP/1.0

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Вашият Proxy-сървър прочита клиентската заявка, вижда че host-a (www.top.bg) е в домайна .bg и връща следния отказ от облужване:

HTTP/1.1 403 Forbidden

MIME-Version: 1.0

Content-type: text/html

Access to .BG domain is restricted.

Contact your system administrator for more details.

Този отговор, без изменения се изпраща на клиента. В случая host-а се взима от URL-то от първия ред на заявката.

Пример 3: Web-браузърът се свързва на порт 3128 към вашия Proxy Server и задава следната HTTP заявка:

GET / HTTP/1.1

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Host: www.niama-takuv-server.com

Вашият Proxy-сървър прочита клиентската заявка и се опитва да се свърже към host-a “www.niama-takuv-server.com” на порт 80, но не успява, защото няма такъв сървър. Затова се на клиента се връща следната грешка:

HTTP/1.0 404 Not Found

MIME-Version: 1.0

Content-type: text/html

Requested document not found!

Хост-а се взима от полето Host на GET-заявката защото в URL-то на първия й ред го няма.

Пример 4: Web-браузърът (в нашия случай Opera 5.12) се свързва на порт 3128 към вашия Simple Proxy Server и задава следната HTTP заявка:

GET http://psstzing.dyndns.org:7001/ HTTP/1.1

User-Agent: Opera/5.12 (Windows 2000; U)  [en]

Host: psstzing.dyndns.org:7001

Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*

Accept-Language: en

Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0

Connection: Keep-Alive, TE

Вашият Proxy-сървър прочита клиентската заявка, променя версията на HTTP протокола, извлича името на host-а, за който е предназначена тя, свързва се към този host (в нашия случай host-а е psstzing.dyndns.org) на порт 7001 и подава преработената HTTP заявка:

GET http://psstzing.dyndns.org:7001/ HTTP/1.0

User-Agent: Opera/5.12 (Windows 2000; U)  [en]

Host: psstzing.dyndns.org:7001

Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*

Accept-Language: en

Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0

Connection: Keep-Alive, TE

Забележете, че вашият Proxy-сървър трябва да вземе името на host-а от реда “GET http://psstzing.dyndns.org:7001/ HTTP/1.1”, а не от полето “Host: psstzing.dyndns.org:7001”, защото URL-то на първия ред е пълно и съдържа host-а. Web-сървърът, който слуша на порт 7001 на адрес psstzing.dyndns.org връща в отговор на тази заявка поискания документ http://psstzing.dyndns.org:7001/ (документа по подразбиране) и затваря комуникационния сокет:

HTTP/1.1 200 OK

Date: Mon, 18 Mar 2002 09:27:51 GMT

Server: Apache/1.3.14 (Unix)  (Red-Hat/Linux) mod_ssl/2.7.1 OpenSSL/0.9.5a PHP/4.0.3pl1

Last-Modified: Mon, 20 Aug 2001 03:37:17 GMT

ETag: "c4fc-c2-3b8085ed"

Accept-Ranges: bytes

Content-Length: 194

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html

Main page

Този отговор, без изменения се изпраща на клиента и сокета за комуникация с него се затвяря. Забележете, че полето host от HTTP заявката може да съдържа IP адрес или host или host:port. Ако не е зададен порт, се подразбира 80 (стандартния порт за услугата HTTP).

Проект 1.4 – Simple Mail Server:

Да се напише програма на Java, която използвайки възможностите на пакета java.net реализира прост Mail-сървър. Програмата трябва да слуша на TCP портове 25 и 110 и да обслужва съответно SMTP и POP3 заявки сългасно SMTP и POP3 протоколите. Сървърът трябва да се състои от 2 части – SMTP сървър и POP3 сървър, които поддържат 3 фиксирани потребителя на системата съответно с имена user1, user2 и user3. За всеки от тях трябва да се създаде пощенска кутия (спъсък от текстови съобщения, който първоначално е празен). Тази пощенска кутия се използва за получаване и съхранение на съобщенията за този потребител. При осъществяване на връзка със SMTP сървъра, той трябва да поздравява клиентите си със съобщението: “220 Simple mail server”. След поздрава SMTP сървърът трябва да отговаря на следните команди:

HELO hostname – връща съобщение “250 Welcome hostname”.

MAIL FROM: <sender_email> – връща съобщение “250 sender_email Sender OK”.

RCPT TO: <recipient_email>

–                                                         ако recipient_email e един от вградените потребители (user1, user2 или user3) връща съобщение “250 recipient_email Recipient OK“.

–                                                         ако recipient_email не e един от вградените потребители, връща “550 recipient_email Recipient not found on this server “.

DATA

–                                                         ако командата RCPT TO е завършила с успех (с код 250), връща съобщение “354 Enter mail, end with "." on a line by itself” след което прочита информацията, която клиента изпраща до срещане на първата точка сама на ред. След това връща съобщение “250 Message delivered” и добавя в пощенската кутия на потребителя-получател (взима името му от команадата RCPT TO) новото съобщение. Предполага се, че текстът на съобщението не може да съдържа редове, които започват със символа точка.

–                                                         ако командата RCPT TO е завършила с неуспех (с код, различен от 250), връща съобщение “503 Invalid state”.

QUIT – връща съобщение “221 Bye” и затваря сокета.

При непозната команда SMTP сървърът трябва да отговаря с: “500 Invalid command”. За командите MAIL FROM и RCPT TO не е задължително e-mail адресите да са заградени от символите “”. Трябва да се позволяват и двата варианта (със и без “”).

При осъществяване на връзка със POP3 сървъра, той трябва да поздравява клиентите си със съобщението: “+OK POP3 server ready”. След това POP3 сървърът трябва да отговаря на следните команди:

USER username – връща съобщение “+User OK, please send your password”.

PASS password

–                                                         ако username съвпада с password и съвпада с ”user1” или с “user2” или с “user3” връща съобщение “+OK”.

–                                                         в противен случай връща съобщение “-ERR Invalid username/password”.

LIST – връща информация за пощенската кутия на потребителя username в следния формат:

+OK X messages

1 YYY

2 YYY

...

X YYY

.

където X е броят съобщения в пощенската кутия на потребителя username, а на следващите X реда стоят числата от 1 до X следвани от размера в байтове YYY на всяко от съобщенията от 1 до X и на следващия ред има една точка (сигнализираща края на списъка).

RETR X

– ако X е валиден номер на съобщение, връща следния отговор:

+OK message X

– ако X не е валиден номер на съобщение, връща отговор “-ERR No such message”.

QUIT – връща съобщение “+ОК Bye” и затваря сокета.

При невалидна команда трябва да се извежда съобщение “-ERR Invalid command”. За да бъдат изпълнявани командите LIST и RETR, е необходимо клиентът първо успешно да е преминал командите user и pass, т.е. да е получил отговор започващ с “+” и на двете. В противен случай командите LIST и RETR връщат съобщение за грешка “-ERR Invalid state”.

Вашият Mail-сървър трябва да бъде програма, която може да обслужва няколко клиента едновременно както по SMTP, така и по POP3 протокола, като се грижи за синхронизация на достъпа до пощенските кутии (става въпрос за синхронизация на достъпа до пощенската кутия като структура от данни в паметта, а не за синхронизация на ниво сесия). Пощенските кутии трябва да стоят само в паметта на сървъра, без да се съхраняват на друго място (и разбира се, да губят съдържанието си при спиране на сървъра). Не е нужно да създавате графичен потребителски интерфейс. Достатъчно е да напишете конзолно приложение, което реализира описаната функционалност.

Пример: Отваряме връзка с Mail-сървъра на порт 25 (SMTP) и водим диалог със сървъра. Командите на клиента са дадени с префикс “Client:”,  а на сървъра с префикс “Server:”. В този пример потребителят се опитва да изпрати поща до непознат за сървъра адрес, а след това изпраща писмо до user1, писмо до user3 и още едно писмо до user1:

Server: 220 Simple mail server

Client: HELO www.nakov.com

Server: 250 Welcome www.nakov.com

Client: MAIL FROM:

Server: 250 mincho_penchov@yahoo.com Sender OK

Client: RCPT TO:

Server: 550 gincho_praschev@abv.bg Recipient not found on this server

Client: Skapan server!

Server: 500 Invalid command

Client: RCPT TO: user1

Server: 250 user1 Recipient OK

Client: DATA

Server: 354 Enter mail, end with "." on a line by itself

Client: Hi, user1!

Client: .

Server: 250 Message delivered

Client: DATA

Server: 503 Invalid state

Client: MAIL FROM: baba_yaga@the-hell.com

Server: 250 baba_yaga@the-hell.com Sender OK

Client: RCPT TO: user3

Server: 250 user3 Recipient OK

Client: DATA

Server: 354 Enter mail, end with "." on a line by itself

Client: Hi, user3!

Client: .

Server: 250 Message delivered

Client: MAIL FROM: baba_yaga@the-hell.com

Server: 250 baba_yaga@the-hell.com Sender OK

Client: RCPT TO: user1

Server: 250 user1Recipient OK

Client: DATA

Server: 354 Enter mail, end with "." on a line by itself

Client: Hi, user1,

Client: Greetings from Baba Yaga!

Client: .

Server: 250 Message delivered

Client: QUIT

Server: 221 Bye

След това отваряме връзка към Mail-сървъра, но този път на порт 110 (където се обслужва услугата POP3) и водим диалог със сървъра.  Опитваме се да взезем с невалидна парола, влизаме успешно като потребител user1 и му прочитаме съобщенията. Отново командите на клиента са дадени с префикс “Client:”,  а на сървъра с префикс “Server:”. Ето и диалога:

Server: +OK POP3 server ready

Client: USER pencho_ginchev

Server: +User OK, please send your password

Client: LIST

Server: -ERR Invalid state

Client: PASS tajna

Server: -ERR Invalid username/password

Client: USER user1

Server: +User OK, please send your password

Client: PASS user1

Server: +OK

Client: LIST

Server: +OK 2 messages

Server: 1 11

Server: 2 37

Server: .

Client: Samo tolkowa li bre? Iskam oshte e-mail!

Server: -ERR Invalid command

Client: RETR 1

Server: +OK message 1

Server: Hi, user1!

Server: .

Client: RETR 37

Server: -ERR No such message

Client: RETR 2

Server: +OK message 1

Server: Hi, user1,

Server: Greetings from Baba Yaga!

Server: .

Client: QUIT

Server: +OK Bye

Проект 1.5 – Simple File Client/Server:

Да се напише програма на Java, която използвайки възможностите на пакета java.net реализира прост файлов сървър. Да се напише програма-клиент за този сървър.

Сървърът трябва да дава възможност на потребителя да вижда файловете в текущата директория, да сменя текущата директория, да изтегля файлове и да изпраща файлове. Началната директория (Root directory) от която се стартира потребителската сесия трябва да е фиксирана и сървърът трябва да дава достъп само до нея и нейните поддиректории. Файловият сървър трябва да слуша на TCP порт 2001 и да изпълнява следните команди, изпратени от клиента:

DIR, LIST, LS – извеждат всички файлове в текущата директория, по един на ред, като за всеки файл се дава името му и дължината му, а за всяка директория се дава името й и