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

есть прога (сервер) , её задача хранить на себе какие то данные , (много мелких 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) И дружно втыкаем это все в одноранговую сеть во время работы программы. Вот и шанс вам

bel_nikita
Вот цитата из RFC.

Цитата(RFC793)

Reliability:     The TCP must recover from data that is damaged, lost, duplicated, or     delivered out of order by the internet communication system.  This     is achieved by assigning a sequence number to each octet     transmitted, and requiring a positive acknowledgment (ACK) from the     receiving TCP.  If the ACK is not received within a timeout     interval, the data is retransmitted.  At the receiver, the sequence     numbers are used to correctly order segments that may be received     out of order and to eliminate duplicates.  Damage is handled by     adding a checksum to each segment transmitted, checking it at the     receiver, and discarding damaged segments.

Цитата(Dubinsky @ 4.7.2005, 12:49)

50 на 50 что пропадёт пакет

Откуда такая статистика? Я в Brood War как-то по UDP играл через диалап(в бруде конечно есть простое модемное соединение, но были некоторые причины, по которым оно было нежелательно).
Юниты бегали правильно

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

пакета дойти искаженным ?

Очень маленький, ибо дейтаграммы UDP имеют 16 битную контрольную сумму. Контрольная сумма пересчитывается при получении пакета и если две checksum не совпадают, то приложение останет в счастливом неведении относительно того что пришел битый пакет(приложение вообще не узнает, что пришёл пакет). Может конечно инфа исказится так, что и checksum'ы совпадут, но никто, даже TCP(у него тоже 16 битная контрольная сумма), от этого не застрохован(кстати, заголовок IP имеет отдельную checksum).

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

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

Если интересен шанс потери, то советую поискать где-нибудь в сети udp эхо сервер(порт 7), который вернёт все полученные им дейтаграммы. А далее расчет:
надежность := 100% * колво-полученных-сообщений/колво-отправленных-сообщений.

Mayk

Цитата(Mayk @ 6.7.2005, 14:18)

Откуда такая статистика?

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

Ага это уже интереснее ...

к примеру в C++ Builder есть такие компоненты , в закладке Fastnet , ну там мыло послать , принять , FTP , а также другая закладка Клиент сокет , Сервер сокет .
Стоит на их основе делать хоть что то мало мальски серьёзное (посыл приём информации несколькими пользователями с сервера ) или это для глупых , ленивых , а по уму ручками(через Winsock ??) надо ?

Цитата(Dubinsky @ 6.7.2005, 17:08)

к примеру в C++ Builder есть такие компоненты , в закладке Fastnet , ну там мыло послать , принять , FTP , а также другая закладка Клиент сокет , Сервер сокет . Стоит на их основе делать хоть что то мало мальски серьёзное (посыл приём информации несколькими пользователями с сервера ) или это для глупых , ленивых , а по уму ручками(через Winsock ??) надо ?

В основе всех этих ServerSocketов ClientSocketов лежат стандартные сокеты(смотреть в Source\Internet\sockets.pas).
Поэтому по большому счету - какая разница? Юзай что хочешь. Лишь бы работало
Просто в случае с билдером не придется изобретать/искать велосипед по отправке сообщений.

так почему ими так редко пользуются ? (TClientSocket - TServerSocket)
дурной тон ?

Цитата(Dubinsky @ 6.7.2005, 18:29)

так почему ими так редко пользуются ? (TClientSocket - TServerSocket) дурной тон ?

Возможно. В последнее время билдером вообще не пользуюсь. Он тормозной(vcl'овские хедеры весят 10 метров. И такое ощушение что они все подцепляются к каждому файлу проекта), не портируемый(CLX? Нет уж, лучше сразу QT, он мощнее и с шаблонами, и попортируемее и дизайнер в нем красивее и хелпа удобнее), непонятный(что за дурное требование о размещении объектов в куче? А может я люблю классы статически размещать, чтоб не заботится о вызове деструктора?) да еще и запускается только из под NTяшек. То ли дело WinSock'и - сделал либу в LNX, добавил инициализацию для виндов, усё. Проблем почти нет.
Хотя если писать всё приложение с использованием VCL, то почему бы и не взять их сокеты? Хуже от этого уже не станет, ведь так?

Это сообщение отредактировал(а) Mayk - 6.7.2005, 17:51

да без ВЦЛ мне уж точно не обойтись в моём проекте , мильон всяких пимпочек , пумпочек , на АПИ если писать на первой сотне сойду с ума , значит уж и не грех использовать ВЦЛ до конца ...