simply_user

TCP защищает от случайных повреждений, для этого к пакету добавляется 32-битная чексума. Вероятность повреждения пакета вообще не очень высока, т.к. чексумы есть еще и на канальном уровне, случайное повреждение такое, что сойдется чексума исключительно маловероятно. Но чексума защищает не от всех повреждений данных и точно не защищает от умышленных. Например если в каждом октете занулять какой-либо бит, то чексума сойдется. Дальше все зависит от ваших потребностей. Но добавлять свою чексуму большого смысла точно нет, если вы хотите более надежно защищать данные - защищайте их криптографически. Вы можете это делать пустив свой протокол поверх SSL/TLS, совсем не обязательно городить защиту внутри протокола.

Подтверждение доставки данных на уровне протокола хотя бы в виде ответа на запрос требуется в любом случае. Если вы откроете сокет, установите соединение, отправите данные и закроете сокет - вы не будете знать дошли они или нет, особенно при работе с асинхронными сокетами.

В нынешнем Интернете это вероятно не нужно. В Ethernet и оптоволокне шумы приводящие к ошибкам, возможны только при грубом нарушении правил строительства сети. В Wi-Fi, xDSL, сотовых сетях обеспечивают больший контроль целостности на канальном уровне. В IPv6 по этому поводу даже чексумму убрали, осталась только в TCP и UDP. Таких ошибок было много во времена Dial-Up, где контроль целостности на канальном уровне был явно недостаточен.

Весь вопрос в критичности — если от битых данных может произойти авария — то проверять еще раз, а если постить котиков, то заморачиваться не нужно.

При условии, что сама эта коллекция будет находится в экземпляре класса RemoteClientViewModel.

Не совсем понял, почему вы называете это "коллекцией", по логике я бы там ожидал увидеть просто несколько обычных свойств, выставленных для вьюхи. Чтобы сделать привязки к этим свойствам, просто задайте нужный ItemTemplate.

Кроме того, мне нужно чтобы при клике на элемент списка ListBox в ListView отображался соответствующий этому клиенту (т.е той ViewModel которая подключена к этому элементу) список файлов.

Всё очень просто - сделайте в MainViewModel свойство SelectedЧТОТО, в пару к вашей коллекции. Например, если коллекция это RemoteClients, то и свойство - SelectedRemoteClient. Забиндите SelectedItem ListBox-а к этому свойству. Разумеется, не забудьте его правильно реализовать, с NotifyPropertyChanged. Затем привяжите ItemsSource ListView-хи к SelectedRemoteClient.Files, где Files это коллекция с информацией о файлах. Если не будет работать, пишите, попробуем другой вариант.

Если вы хотите показывать информацию для выбранного RemoteClient, то можно в MainViewModel добавить поле SelectedRemoteClient и забиндить его на SelectedItem в ListBox(которые содержит RemoteClient). Ну и потом юзать его в ListView.

Привет!
Насколько я знаю, сертификацию MCSD нужно подтверждать каждые 2 года.
А MCPD, да, устаревший. То же самое, только название другое.
Ценится и тот и тот, но новее лучше..

ViewModel - это то, что должна отобразить View )). Фактически, это адаптированная для View Model.

Взять из массива A элемент с индексом n.

Блокировки не нужны. Но просто так записывать и читать поля из разных потоков тоже нельзя.
Вот смотрите: предположим, у вас многопроцессорная система. Один поток выполняется на одном процессоре, другой - на другом. У обоих процессоров есть свой кэш (точнее, несколько уровней кэшей). Если первый поток изменяет переменные (не важно, статические они или нет), то они не попадут в оперативную память до тех пор, пока процессор не сбросит кэш при помощи специальной инструкции. Поэтому, второй поток будет продолжать думать, что данные не изменились.
Для того, чтобы процессоры правильно работали с такими общими переменными придуманы барьеры памяти (memory barriers). Есть несколько способов поставить такие барьеры:
1) методы Thread.MemoryBarrier() / Thread.VolatileRead() / Thread.VolatileWrite()
2) добавить к полю модификатор volatile
3) использовать методы класса Interlocked
4) Использование блокирующих примитивов синхронизации (Monitor, ReaderWriterLockSlim, Events, Semaphores, Mutexes, etc.)

Без контекста задачи не ясно, что вам подойдёт в вашей задаче, но похоже, что достаточно пометить поля модификатором volatile.

Класс thread понимает только функторы. А методу класса нужен еще указатель на сам класс. Поэтому указатель на метод вместе с this надо завернуть в функтор. Сейчас это красивее всего делается с помощью labmda функции. Еще можно использовать std::bind, сделанный специально для таких случаев, но ИМХО лямбда лучше читается.

1. Сама Windows многое кэширует
2. На мой взгляд I/O операции следует разделять только тогда, когда другие вычислительные процессы достаточно длительные и I/O поток будет успевать к очередному запросу прочитать, иначе зачем?