/lpProject

Репозиторий для практики первого курса 2К16.

Primary LanguageC++

## lpProject

План занятий, 1 курс, практика

21.06
	
1 Пара
		
1.0 Рассказать, что им надо поставить и как это ставить: 
Unix им ставили, в любом случае - это их проблема, во вторник он должен быть. Компиляция и запуск программ в Unix (с 1 или несколькими файлами + фоновый запуск программ).
1.1 Опрос по С++ беглый, 20-30 минут: 
	классы, 
	ООП, 
	конструкторы - деструкторы, 
	семантика копирования, 
	ссылки - указатели, 
	перегрузка и виртуальные функции.
1.2 Рассказать про все на чем вывалятся
Если мы хотим, чтобы они писали С++ код, без 1.1 и 1.2 никуда не деться.

2 Пара
	1.1 Идея межпроцессорного взаимодействия
	1.2 Средства межпроцесорного взаимодействия Windows: 
		сокеты, 
		каналы, 
		файлы проецируемые в память,  
		сообщение WM_COPYDATA
	1.3 Средства межпроцесорного взаимодействия UNIX:
		проецируемый в память файл,
		сигналы,
		сокет,
		канал / именованный канал, 
		разделяемая память
Вот тут по мимо рассказа со второго курса хотелось бы видеть примеры кода. 
Примеры не обязательно сложные, главное чтобы было им понятно. Дальше, на практике они пытаются эти примеры кода набрать, скомпилировать, запустить.

22.06 

1 Пара 
	1.1 Рассказать об общей идее, что мы планируем сделать. 
	1.2 Рассказать о проблемах использования голых средств IPC и о необходимости С++ оберток над ними. 
	1.3 Идиома RAII на простом примере. 
	1.4 Реализация этой обертки для сокетов Unix/Windows. 
На консультации продолжение, в идеале – кто-то из наших при них набирает код, а они повторяют. 
Задач у обертки всего 2: первая - инициализация сокета в конструкторе, уничтожение в деструкторе + сделать так, чтобы его нельзя было скопировать - запретить конструктор копий, вторая задача — это независимая от системы обертка. 
В идеале сделать это так (простой пусть, немного неэффективный, но им сойдет):
1. Сделать 1 абстрактный класс (base_socket) с несколькими чисто виртуальными методами (send, recieve, accept, bind, …). 
2. Пронаследовать от него 2 класса, (unix_socket) и (windows_socket) где реализовать эти классы с API конкретной системы, причем важно чтобы они были в разных файлах. 
3. Сделать еще 1 класс, (socket) который:
    1. Реализует семантику запрета копирования (ибо нехуй объекты ядра копировать), и я рассказывал у себя на парах это (если вкратце - сделать класс с приватным конструктором и оператором копирования и отнаследовать обертку от этого класса). 
    2. Наследуется от абстрактного класса, 
    3. Содержит в себе указатель на абстрактный класс и условной компиляцией на этот указатель создает unix_socket / windows_socket в зависимости от платформы.
Со второго курса - реализация. 
И очень важно на паре объяснить эту архитектуру, чтобы до них дошло, зачем им создавать 5 классов и почему такие связи между ними. 




24.06
	1 Пара 
		1.1 Идея простого tcp - эхо сервера и использованием уже написанных оберток. 
	2 Пара 
		1.2 Многопоточный сервер - один поток слушает входящие запросы, и на каждое соединение создает дополнительный поток, в котором вертится обмен данными. (вот тут бы в идеале тоже придумать обертки над потоками с целью платформонезависимости). 
Exo сервер означает, что сервер только отсылает обратно то что принял от клиента. 
На консультации собственно реализация этой хуй… технологии. 

28.06 
	Проблема поиска среди больших объемов данных. 
	Деревья (общая логика) ибо чтобы они не завафлили где ниубудь на вопросах костикова на 2 курсе. Хэш таблица - теория + реализация на 2 паре и консультации. 
Если никто вафлить не будет, то должны успеть. 

29.06 - 30.06
	Протокол передачи данных ftp (о нем бы почитать 2 курсу). 
	Реализация контрольного соединения, по которому шлются команды
	Реализация соединения с данными. 
Пояснение: 
	Логику я вижу такую: 

Есть класс сервера. У него есть один сокет, который слушает запросы, есть хэшмапа. Поля такие: 
Клюс - строка (название файла на сервере), 
Данные - структура с полями: 
	1. Реальный путь к файлу, 
	2. Флажок использования файла. (Если один клиент скачивает файл, или загружает, то этот флажок будет в true). 
При каждом подключении, он (сервер) создает новый объект класса control_connection.  Так же его задача при завершении работы (деструктор), все эти объекты грохнуть. 
Класс контрольного соединения (control_connection). В его задачи входит обработка входящей информации и интерпретирования ее как команд. 
Над списком команд надо подумать - все зависит от того, как успевать по времени будем. Но основных будет 2 - загрузить файл и скачать файл. Если загружаем файл, то в хэшмапе сервера создается и блокируется новая запись, если скачиваем файл, то из хэшмапе сервера ищем и блокируем запись. Далее в обоих случаях из той же хэшмапы надо получить строчку с реальным местонахождением файла, и создать объект класса data_connection.
Класс соединения с данными. В его задачи входит считывание / запись в  файл, и организация цикла передачи данных от клиента или отправки данных с сервера. 

Клиент простецкий - с терминала получить команду на сохранение / получение файла, отправить на сервер и получить / скачать файл на кампухтер по какому-нибудь пути. 

Собственно, сервер реализуем мы, а на зачет (4.07) либо с них клиент, либо (если слишком пиздец) они отвечают по теории. 

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