Mozzarella

Можно картинкой вставить. Просто. Быстро. Размер шрифта начинает отличаться от остальной страницы при адаптивном уменьшении картинки. Печаль для дизайнера-перфекциониста. А еще буквы могут начать мылиться. Это вообще печаль. Если нужно добавить/убрать стрелки - придется перерисовывать картинку. Это неприемлемо, если к ним привязана какая-то еще логика и они показываются не всегда.

Можно использовать связку SVG+CSS:
- Берется SVG с viewbox='0 0 100 100'.
- Основная картинка вставляется в виде image.
- Стрелки рисуем в векторе (это просто дуги из одной точки в другую с маркером на конце).
- Если нужно сделать их двухцветными, как в вашем примере - делаем маску по картинке и применяем ее к стрелкам.
- Надписи верстаем отдельно (div`ами) и абсолютно позиционируем сверху. Координаты будут соответствовать им же в svg (от 0 до 100). Это нужно для того, чтобы сохранять размер шрифта при адаптивном уменьшении всего этого.

Дальше при необходимости мы можем легко из css или js показывать или скрывать надписи и стрелки.

1. Убрать все "lock" - никакой пользы от них здесь нет.

2. Убрать все "try {...} catch (Exception e) { Debug.Print(e.Message); }
Никакой пользы от них тоже нет.

3. Убрать IsCorrect. Читаем длину сообщения, затем читаем нужное количество байт. А то, что вы называете "Фактическая длина" - плод вашей фантазии.

4. Читать надо ни до тех пор, пока DataAvailable, а до тех пор, пока не будет получено нужное количество байт. Синхронно, либо асинхронно вы это будете делать - без разницы.

5. А теперь собственно ответ на ваш вопрос:
Механизм чтения сообщений умирает, когда читатель читает быстрее, чем писатель пишет (либо сеть передает). В этом случае DataAvailable вернет false; ваш алгоритм, вместо того, чтобы дождаться оставшейся части сообщения, прерывает чтение на середине сообщения, говорит, что IsCorrect() == false, и зависает.

6. Формат сообщения имеет смысл упростить: первые 4 байта - длина тела в байтах; затем само тело (например, в UTF-8, если вам нужен текст). Соответственно, читаем сначала 4 байта, а потом еще столько, сколько там указано.

P.S.
7. Вызывать Encoding.GetString() следует только на целом сообщении; если вы делаете это на части сообщения - результат непредсказуем.

8. Сетевые исключения обрабатывать, конечно же, надо. Однако Debug.Print - это не решение проблемы. Сокет имеет смысл закрыть. А дальше - либо уведомить об этой проблеме своего клиента (кто обрабатывает полученные сообщения), либо, по-хорошему, - попытаться открыть другое соединение и повторить попытку продолжить работу так, чтобы клиент ничего не заметил :)

Если правильно - подключить DI Container, делать все через него.

Если без контейнера - передавать зависимости вручную. Обычно они не нужны везде

То, о чем вы рассказываете лично я делал несколько иначе. Событий, как таковых, нету. Есть команда, которая и есть событием. Например AttackCommand, MoveCommand, DeployCommand. Все взаимодействие идет через команды, все остальные классы - сухие данные. Соответственно всякие такие вещи нужны только командам, а они создаются через единый центр, который и делает инъекцию.

Тут я писал статью:
https://habrahabr.ru/post/322258/
https://habrahabr.ru/post/322268/

А еще, если напишете на емейл (есть в профиле), могу скинуть пример сервера ККИ на C#.

1. Для Accept у вас лишний поток. Куда лучше сделать подключение новых клиентов через BeginAcceptTcpClient
2. Дальше тоже лучше использовать асинхронные запросы

var stream = tcpClient.GetStream();
var asyncResult = stream.BeginRead(buffer, 0, READ_BUFFER_SIZE, ReadStreamCallback, null);

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

Правильно заметили, что есть люди-исполнители, а есть люди-генераторы идей. Нужно реально взглянуть на себя и...принять это. Быть профессиональным исполнителем гораздо кошернее, чем быть генератором провальных идей. По статистике, 9 из 10 стартапов провальны...зачем пополнять собой этот список? Если ты - рыба, то многого ли ты добьешься от фрустрации по поводу неумения залезать на дерево?

Самый верный путь к рабочей идее:
1. Проработать в какой-либо сфере достаточное количество времени;
2. Познать её изнутри на собственной шкуре;
3. Выявить в ней боли/проблемы/недостатки;
4. Решить их с помощью прикладного навыка (программирования);
5. Обкатать в собственной работе;
6. Упаковать решение и реализовать коллегам по сфере;
...
7. PROFIT!

Далее...даже если завтра в голову залетит рабочая идея, готов ли ты её реализовать? У тебя есть команда, готовая работать минимум полгода-год бесплатно на время создания беты, тестов, обкатки, раскрутки? Она сможет действительно реализовать всё как надо? Если нет команды, имеются ли у тебя средства на зарплатный фонд хотя бы для 5 человек на эти полгода-год? А с учетом налогов и отчислений (+30% к зарплате на руки)? У тебя есть условия для работы этих 5 человек? Есть ли у тебя сумма на маркетинговое исследование твоей идеи (или лучше облажаться на авось)? Есть ли у тебя хотя бы миллион на первичный трафик из директа? Или надеешься донести свой стартап до пользователей путём емэйл-спама?)) Я не указал и доли того, что потребуется для реализации небольшого web-сервиса, даже при наличии действительно рабочей идеи. Может быть, идеи не прут именно потому, что ты просто не готов к их реализации, и неча порожняка гонять?)

Как выглядит стартап глазами романтичного юноши, начитавшегося глянцевых историй успеха:
1. Придумать гениальную идею;
2. Закодить в гараже в одну харю или в паре с дружбаном;
3. Разместить на сервере и получать от мира благодарности, признание и мешки денег.

Как выглядит стартап на самом деле:
1. Пахота минимум 10 лет в одном направлении/сфере;
2. Наработка профессионализма, идей, контактов, связей, клиентской базы, понимания всех нюансов сферы;
3. Угон базы, угон клиентов на себя, переманивание лучших коллег/сотрудников, оформление юрлица, открытие "своего дела" на рабочей идее)))

К примеру, "икона стиля" стартаперов - Павел Дуров, он идеолог? Нет! Прикол в том, что он именно стырил рабочую идею (также, как тырят клиентскую базу у работодателя), собрал команду, создал для неё условия, привлек корешей-евреев с еврейскими ресурсами, бюджетами и влиятельной питерской крышей, и обеспечил этому всему грамотный проект-менеджмент и маркетинг. Дело в идее? Нет, дело в реализации:)

А если серьезно, сайт - это просто промо-материал, как билборд, только интерактивный и в интернете. Языки веб-разработки - такие же инструменты, как молоток для изготовления билбордов. Веб-разработчик - нифига не носитель уникальных знаний (который просто обязан повторить успех Цукерберга, иначе не тру), и всего-лишь современный слесарь, изготавливающий технологичные интерактивные промо-материалы. А теперь представь слесаря, который завидует предпринимателям, которые заказывают у него билборды, и вскидывает руки к небу с криком "Доколе??")) Смешно? Смешнее только реплики других слесарей на тему "если нет идей, значит меняй профессию"))

P.S. Понимаю, что вряд ли отметишь мой ответ решением, ведь тебе хочется подбадриваний вида "Не сдавайся! Ищи и обрящешь! Не опускай руки и всё получится! Вот тебе ссылочки, вот тебе инструкции!", а не режущей глаза суровой реальности. Но в некоторых случаях действительно полезно осознать своё место в пищевой цепочке - антилопа или гепард, слесарь или архитектор, промо-изготовитель или промо-заказчик и т.д. И исходя из этого уже взращивать свои амбиции, комплексы и фрустрации. Повторюсь - в стремлении стать самым крутым слесарем нет ничего постыдного, и даже в финансовом плане может оказаться куда выгоднее и стабильнее других амбициозных вариантов.

Создать класс:

class Entity {
   public double X = 0;
   public double Y = 0;
   public double Z = 0;
}

class Element : Entity {
  public string color = "red";
}

class Room : Entity {
  public List<Element> objects;
  public void Add(Element obj) {
    objects.Add(obj);
  }
}

class Door : Element{
  public string style = "modern";
}

class Window : Element{
  public string material = "wood";
}

Room room = new Room();

room.Add(new Door());
room.Add(new Window());

1. https://developers.google.com/web/tools/chrome-dev... (для Firefox есть подобное)
2. https://www.browserstack.com/ (первые 30 минут бесплатно)

На 5.6 работает вот так.
Пример для загрузки в диалог:
(важно, смотрите в документации, в диалог фото грузится в поле photo, в другие места может грузиться в поле file).

$photo = 'file.png';
    $postparam=array("photo"=>"@".$photo);
    $ch = curl_init($request_server->response->upload_url);
    curl_setopt($ch, CURLOPT_SAFE_UPLOAD, false);
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS,$postparam);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: multipart/form-data; charset=UTF-8'));
    $upload = json_decode(curl_exec($ch));
    curl_close($ch);

Для php7 используется CURLFile и CURL без параметра CURLOPT_SAFE_UPLOAD
"photo"=> new CURLFile($photo)