История изменений

За буфером следит asio. Там нужно только не накосячить с параллельным вызовом такой же асинхронной функции. Или имеешь ввиду что-то другое?

Берешь эталон: вот конкретно такой запрос бинарно выглядит так. Программно генерируешь этот запрос, сравниваешь с эталоном. Вот тебе и еще один тест.

Клиент читает 8 байтное число, а не 8 байт.

А в чем разница? :) UPDЯ все понял, сорри :)

В смысле кодировка имен файлов в кирилице или что? Имена то не в кирилице.

Описание программы, Тестовое задание UNIX.

А каким образом она описывается? UML диаграммы что-ли строить? Что же все так жирно нужно делать.

Я предпочитаю текстом, можно что-нибудь и вроде UML. В клиент-свервеном софте ИМХО самая понятная модель описания – dataflow. Ты начинаешь описание с того, в какой класс/метод приходит запрос и описываешь его жизнь до выхода наружу. Ну и аналогично в клиенте. Это позволит построить в голове твое решение и уже знаючи лезть в конкретные файлы исходников за деталями.

Что же все так жирно нужно делать.

Ну я не знаю, на какую позицию ты претендуешь, но вообще я придерживаюсь мнения, что при написании домашнего задания ты выполняешь свою первую работу, и выполнять ее нужно от и до – работодатель должен рассматриваться в качестве клиента. И тут уже от тебя зависит, насколько ты хочешь устроиться в конкретную компанию на конкретную позицию, а значит насколько хорошо готов выполнить задание, и сколько времени на это потратить.

За буфером следит asio. Там нужно только не накосячить с параллельным вызовом такой же асинхронной функции. Или имеешь ввиду что-то другое?

Берешь эталон: вот конкретно такой запрос бинарно выглядит так. Программно генерируешь этот запрос, сравниваешь с эталоном. Вот тебе и еще один тест.

Клиент читает 8 байтное число, а не 8 байт.

А в чем разница? :)

В смысле кодировка имен файлов в кирилице или что? Имена то не в кирилице.

Описание программы, Тестовое задание UNIX.

А каким образом она описывается? UML диаграммы что-ли строить? Что же все так жирно нужно делать.

Я предпочитаю текстом, можно что-нибудь и вроде UML. В клиент-свервеном софте ИМХО самая понятная модель описания – dataflow. Ты начинаешь описание с того, в какой класс/метод приходит запрос и описываешь его жизнь до выхода наружу. Ну и аналогично в клиенте. Это позволит построить в голове твое решение и уже знаючи лезть в конкретные файлы исходников за деталями.

Что же все так жирно нужно делать.

Ну я не знаю, на какую позицию ты претендуешь, но вообще я придерживаюсь мнения, что при написании домашнего задания ты выполняешь свою первую работу, и выполнять ее нужно от и до – работодатель должен рассматриваться в качестве клиента. И тут уже от тебя зависит, насколько ты хочешь устроиться в конкретную компанию на конкретную позицию, а значит насколько хорошо готов выполнить задание, и сколько времени на это потратить.