Вопрос вот в чём ...

есть прога (сервер) , её задача хранить на себе какие то данные , (много мелких 500 - 4000 байт файлов часто меняющихся)

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

2) плюс есть некий компутер не в локалке который должен иметь полный доступ к серверу и возможность передавать некие данные и команды.

какие способы для работы с локальной и глобальной сетями посоветуете в данных двух случаях посоветуете ? (хотелось бы )

передадут ли эти способы данные гарантированно без потерь или искажений ?

вообще возможно ли передать данные гарантированно без потерь ? (и что для этого нужно делать ?)

язык : Ц++ Бульдер
программер : Я , неплохой но с сетью на Вы !

/*ИМХО
1) Про целостность... естественно нужно добавить уникальный код версии в каждый файл, дабы избежать тупого использования трафика aka закачка одного и того же.
2) Зачем компьютер ?
Ты чего делаешь статичную систему ?
Оперируй пользователями... выделяй аккаунты... наконец оставь один уникальный аккаунт админу.

Самый сложный, но гарантированно велосипедно-генераторный(во какое слово) юзать напрямую интерфейс winsock для виндов и аналог для *nix. Зато можно хоть чему-то научиться.

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

"""передадут ли эти способы данные гарантированно без потерь или искажений ?"""
Если использовать протоколы высокого уровня, и соответсвенное АПИ, то все дело сводиться к SendMessage() ReciveMessage() естественно со стандартной ассинхронной поддержке.
Если же использовать сокеты и функции send-recv(для виндов), то здесь надо следить и за блокированием и за целостностью. Исключением для некоторых недостатков являются Ассинхронные сокеты, применение которых тоже предьявляет ряд требований( не использование консоли, как главного окна приложения)

Совсем же антицелостным( ) является передача данных дейтаграмами. Это 50 на 50 что sendto что-то доставит. Зато UDP имеет одно, но пожалуй самое значимое преимущество - вещание в режиме BROADCAST aka радио. Приминение UDP - это ИМХО единственный выход для сетевых игрушек( Открой Quake 2 и посмотри при загрузке сетевой сессии посмотри эхо-вывод в консоле)

ЗЫ для твоей задачи я бы юзал Ассинхронные сокеты...
Хотя покопай в сторону TSocket( или как там В Билдере называется компонент-оболочка сокетов ?)

"""программер : Я , неплохой но с сетью на Вы !""""
Очень странная фраза возможно имелось ввиду: "Я программер неплохой, но с сетью никогда не работал"
Если я ошибься, то тогда зачем было постить общий вопрос ?
ИМХО*/

Цитата(En_t_end @ 1.7.2005, 19:41)

Если использовать протоколы высокого уровня, и соответсвенное АПИ, то все дело сводиться к SendMessage() ReciveMessage() естественно со стандартной ассинхронной поддержке.

Вообще-то обычно надежность зависит от протокола. TCP является более надежным, так как ОС отправителя отслеживает за тем, чтобы все сообщения были отправлены(данные НЕ будут удалены из буфера отправки сокета, пока удаленная система не пришлет подтверждение. Если после некоторого времени подтверждения нет, то данные пересылаются снова), а ОС получателя следит за тем, чтобы все сегменты сообщения пришли в правильном порядке и только один раз(порядок сегментов может быть нарушен маршрутизаторами). При использовании протокола UDP такой халявы не будет в помине. Приложение всё должно обрабатывать само. Отправитель может отослать три сегмента А,Б,В, а получатель может получить их (теоретически) как четыре сегмента В,В,В,А. Тогда приложение должно само заметить дублирование В,отсутствие Б и неправильный порядок. Разумеется, в локальной сети шанс искажения с использованием УДП минимален.
Хотя может борландовцы и добавили надежности.. Не знаю, не могу посмотреть, ибо из борлы только freebcc стоит

Цитата(En_t_end @ 1.7.2005, 19:41)

то здесь надо следить и за блокированием и за целостностью.

Теперь насчет блокирования. В маздае сокет можно сделать неблокируемым с использованием функции ioctlsocket(в нормальных системах для этого используется fcntl, ну да ладно)

Код

unsigned long rc=0xffffffff; //не ноль включает неблокируемый режим ioctlsocket(sock,FIONBIO,(unsigned long*)&rc);

Всё. Теперь сокет переведен в неблокируемый режим.

__Mayk
Спасибо.
"""Вообще-то обычно надежность зависит от протокола. TCP является более надежным, так как ОС отправителя отслеживает за тем, чтобы все сообщения были отправлены"""
В той части, которую ты цитировал, я имел ввиду протоколы высокого уровня, но происхождением от TCP. Таковым является SOAP(+ родство с xml) к примеру.

"""Теперь насчет блокирования. В маздае сокет можно сделать неблокируемым с использованием функции ioctlsocket(в нормальных системах для этого используется fcntl, ну да ладно) """
Хм...тогда возникнет другая проблема - проблема целостности, я думаю здесь лучше оперировать таймаутами.

Цитата(En_t_end @ 2.7.2005, 08:58)

Хм...тогда возникнет другая проблема - проблема целостности

Не пойму от чего тут возникает проблема целостности? TCP чертовски надежён(ища(а вдруг?) опровержения набрал в гугле "ненадежность TCP" и "надежность TCP". В первой ссылке о надежности классная фраза: "Надёжность TCP позволяет всякому Остапу Бендеру из Восточной Африки рассылать по миру спам наивысшего качества." ) Или мы говорим не о целостности передачи данных, т.е. чтобы принимающая сторона получила то, что отправила отправляющая бит в бит?

Цитата(En_t_end @ 2.7.2005, 08:58)

Таковым является SOAP

Ух, ну не знаю. SOAP не использовал. Какой-то он растратный (Пример из вики):
"The client needs to know which product corresponds with the ID 827635"

Код

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">    <soap:Body>      <getProductDetails xmlns="http://warehouse.example.com/ws">        <productID>827635</productID>      </getProductDetails>    </soap:Body>  </soap:Envelope>

(много байт) вместо(например):

Код

buffer_t buf; buffer_add_int8(&buf,CMD_GET_PRODUCT_INFROMATION); buffer_add_int32(&buf,827635); //предполагается, что add_int32 ложит инетегер в сетевом порядке байт send(sock, buffer_data(&buf), buffer_length(&buf), 0);

(5 байт) ИМХО это не так растратно для трафика... Хотя для каждой задачи свои инструменты, спорить не бу.

Dubinsky

Цитата

какие способы для работы с локальной и глобальной сетями посоветуете в данных двух случаях посоветуете ? (хотелось бы )

TCP/FTP

Цитата

тут мне интересно какой шанс искажения информации присутствуют у разных способов работы с сетью и какие эти способы бывают

При TCP никакого искажения информации не будет. Возможно только, что первый пакет придет последним Поэтому для обмена файлами лучше использовать FTP

Цитата(bel_nikita @ 2.7.2005, 12:31)

Возможно только, что первый пакет придет последним smile

В TCP это исключено. Все дружно курим RFC793 и другие умные вещи:

Цитата

Давайте посмотрим, что происходит на принимающем конце. Когда обычные данные приходят последовательно (сегмент 43), принимающий TCP передает 256 байт данных пользовательскому процессу. Однако следующий принятый сегмент (сегмент 46) не в порядке; стартовый номер последовательности данных (6913) не является следующим ожидаемым номером последовательности (6657). TCP сохраняет 256 байт данных и отвечает посредством ACK с самый большим номером последовательности, который был принят успешно, плюс один (6657). Следующие семь сегментов, принятых vangogh (48, 50, 52, 54, 55, 57 и 59), также не в порядке. Данные сохраняются принимающим TCP, и генерируются дублированные ACK. Таким образом, для TCP не существует способа сообщить удаленному концу, что сегмент отсутствует. Помимо этого TCP не может подтвердить поврежденные данные. Все что может сделать vangogh в подобном случае - это продолжать посылать ACK с номером 6657. Когда прибывают отсутствующие данные (сегмент 63), принимающий TCP имеет в своем буфере байты данных 6657-8960. Он передает эти 2304 байта пользовательскому процессу. Все 2304 байта подтверждены в сегменте 72. Также обратите внимание на то, что этот ACK объявляет окно равное 5888 (8192 - 2304), так как пользовательский процесс не имеет возможности прочитать 2304 байта, которые уже готовы для него.

Кстати, для UDP можно еще посоветовать TFTP протокол. Хотя он довольно медленный по сравнению с FTP.

Это сообщение отредактировал(а) Mayk - 2.7.2005, 12:54

Mayk

Цитата

Цитата Возможно только, что первый пакет придет последним Цитата В TCP это исключено. Все дружно курим RFC793 и другие умные вещи:

Курить ничего не надо, я недавно бросил Я имел ввиду, что если посредством TCP/IP передавать данные. Т.е. мы хотим передать 1Мб инфы. Естественно разбиваем эти данные на TCP-пакеты и посылаем. Так вот, первый высланный пакет может прийти последним

"Какой-то он растратный"
Я тоже так считаю, поэтому его не использую. В данном контексте я имел ввиду сложность работы с АПИ чисто в функциональном плане...

Уфф спасибо , глубоко копнули ...

Разгребусь за недельку с интерфейсом и полезу сеть делать ... наверняка появятся вопросы новые ...

видимо удел мой ТЦП , ФТП ...

а насчет игр и УДП если он такой ненадёжный то какого ... его используют ?
это из - за широкополоспого вещания только то ?..
Разве нельзя по ТЦП всем передавать что либо Бродбандом , глупость какая то , чтобы всем компам пошла инфа её нужно сначала потерять по УДП ? ;)

ну да ладно я бы лучше всё равно ничего лучше бы не придумал ...

UDP - это не только широковещание(хотя для игр с 1000 игроков это довольно важно). Это прежде всего скорость. Но все лучшее требует жертв... на самом деле udp не контролирует соединение, потому что его просто нет Допустим коннектиться игрок к серверу - сначала он ИМХО проходит этап идентификации по TCP дальше соединение перехватывается и весь обмен идет через UDP. Это позволяет безболезненно для всего процесса быстро и легко "извлечь" игрока из игры, если вдруг произошел обрыв. Просто на очередной проверке неблокируещего вызова путем посылки своей трассирующей инфы через sendto, ответа не поступило, то "игрока" удаляют из списка подключенных - с ним разрывается и tcp соединение. Обычно посылка трассирующей инфы, как путем средств tcp, так и udp называют в геймерских кругах "пингом". Протокол "пинга" - это протокол низкового уровня, стоящий ниже чем udp и tcp и я не уверен, что, допустим, в контр-страйке трассировка идет именно по нему. СУВ

ну соединение гарантирующее скорость а не дошедшие данные сомнительно , неужели так плохо с УДП всё ? 50 на 50 что пропадёт пакет ... Да как вообще все эти сети пашут ...
Как бывший кабельщик вообще не верю что инет может пахать
Добавлено @ 11:50
мдаа инет тормозит игроиндустрию ...

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

вот всем кажется , а есть какая нибудь информация о том какой шанс у

пакета дойти искаженным ?
от чего это зависит ?
наверняка шанс ничтожный но ведь есть ?

Цитата(Dubinsky @ 4.7.2005, 19:30)

наверняка шанс ничтожный но ведь есть ?

Берем кабель один конец-локалка другой-питание(220) И дружно втыкаем это все в одноранговую сеть во время работы программы. Вот и шанс вам