AlexeyStafРазбираюсь с сокетами. ....Какие есть еще варианты обмена ошибками между клиентом и сервером?

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

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

Вы можете кстати реализовать своё извещение об ошибке (через тот же UDP). Но если TCP сдох, то думаю Ваша нахлобучка вряд ли прокатит (обрыв провода к примеру).

Необходимо упомянуть, что в протоколе TCP есть такие весчи как СРОЧНАЯ передача данных и ПРОТОЛКНУТЬ данные до кода другой стороны из стэка TCP. так же если происходят сбои, то регламентируеться передача извещения об ошибки на таких протоколах как ICMP (ну к примеру... Пакет не может быть обработан - погиб. Либо - подожди немного, щаз переварю предыдущие пакеты).

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

с уважением
(круглый)

AlexeyStafА что Вы можете сказать по поводу сокетов и Firewall? Какие трудности могут возникнуть?

либо проходит, либо нет...возможно сваливаеться в лог куда нить... время жизни на единичку возможно меньше, при проходе... вроде всё...


с уважением
(круглый)

AlexeyStafСмотрите, тут вот какая заморочка получается. Я работаю с CSocket, хотел использовать протокол TCP, чтобы была гарантия доставки сообщений (пакетов). Но у меня получается так, что эти TCP пакеты передаются по UDP протоколу (передача идет по VIP каналу). Что можно тут сделать? Просто получается, что некоторые пакеты не доходят, а некоторые приходят битыми :(

стоп..стоп..стоп...
в TCP нет понятия пакетов... (по крайней мере на пользовательском уровне)... это всё скрыто от Вас... и не должно волновать апсалютно никаким образом.т.е. повтор, досылка, контроль целостности - это всё проблемы TCP слоя (ну и IP ессесвенно).

Другими словами...
Если у Вас есть канал в котором существует сегмент где происходит потеря какого то процента данных (договорились, что КАК - это не Ваши заботы) - то может быть две ситуёвины...а) Вы не установите соединение...б) передача будет вестись с учётом потери некоторого процента данных... То что Вы увидете наверху - думаю не сложно предположить... в случае А - не сможете соединиться...в случае Б - передача будет медленнее...


По поводу дохода пакетов битыми...ышо раз повторяю... на TCP уровне - енто ФИЗИЧЕСКИ НЕ ВОЗМОЖНО... Или скажем так спецификацией протокола это ЗАПРЕЩЕНО ! Либо идёт речь НЕ о TCP.

с уважением
(круглый)
ЗЫ
На всяк случай типичные ошипки...
1) Предположение, что Вы получаете некие кванты - "пакеты" на стороне клиента. При попытке передачи квантами - пакетами. Такого "регламента" нет в TCP !
2) Что передача ведёться "моментально". См. настройки слоя TCP на Вашу OS.
ЗЫ ЗЫ
По поводу битости...Это про то, что Вы вели речь (по слоям)...
Уровень IP - разбивка на пакеты не более 1500 (как правило). Проверка CRC существует.
Уровень TCP - разбивка на сообщения. Длина, частота и обьём - определяеться в процессе связи. Проверка CRC существует.

AlexeyStaf...Клиент(Сервер)->TCP->UDP->TCP->Сервер(Клиент)

UDP - протокол передачи дэйтаграм. Не гарантирует доставку пакетов адресату. Использует следующий стэк...UDP->IP->Ethernet->IP->UDP
TCP - протокол связи точка-точка. Гарантирует последовательную(!) доставку данных адресату. Другими словами это надёжная труба в две стороны. ФИФО если хотите. Использует следующий стэк... TCP->IP->Ethernet->IP->TCP

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

Если Вы работаете в своём клиенте с UDP соской - то придёться ожидать а) возможную потерю пакетов. б) не последовательный приход пакетов

Если Вы работаете в клиенте с TCP соединением - то нуна помнить, что запихнув в трубу последовательность "AB" + "CD" Вы и получите на выходе "ABCD". Будете дробить этот поток на кванты - это Ваше дело. Будете воспринимать как файл (поток) - Ваше дело...

с уважением
(круглый)

AlexeyStafСмотрите как у меня происходит все ЭТО. Между двумя компьютерами настраивается защищенный канал, по нему все пакеты передаются по UDP протоколу. Затем клиент подключается к серверу по TCP протоколу. Вот и получается, что клиент и сервер формально обмениваются по TCP, а на самом деле по UDP. Или я это уже я не так понимаю что-то?
Т.е. при использовании у меня может получиться такая ситуация: послав пакеты "A"+"B"+"C"+"D", я могу получить на другом конце что-то вроде "A"+"D"+"B". Вроде бы так может получиться. Но как тогда с этим бороться? Я понимаю, что тут надо контролировать доставку и целостность дэйтаграм, но не писать ведь мне свой собственный протокол, основанный на UDP :(

1) "клиент подключается к серверу по TCP протоколу" Если это действительно так - то Все рассуждения о физическом формате пересылаемых данных - тут не у дел. С родни: "а на улице зима и солнышко"... Со стороны Ваши рассуждения выглядят приблизительно так...

У меня провода идут на 5 этаж ! Байтам будет тяжело или по фигу, если учесть, что периодически происходят наводки от дроби в животиках крыс, бегающих вдоль провода ?

2) Если идёт речь о TCP..."AB" + "CD" - это не пакеты имелось в ввиду, а данные...буковки то бишь...И если они были отправлены в такой последовательности, то так и будут получены (имееться ввиду последовательность). "ABCD". По поводу "может получиться" - ответ: НА УРОВНЕ TCP НЕ (!!!) МОЖЕТ... тэчека...см. спецификацию протокола...

3) Если Вам так хочеться написать свой протокол - Вы можете использовать любой уровень, в том числе и UDP. В реализации есть свои плюсы... А именно: не жрёте ресурс под названием TCP connection, соответственно обходите это ограничение (если оно стоит), так же поймёте как реализован TCP протокол внутри.
А так же минусы: если не правильно реализовали такие весчи как "медленный старт", разрешения колизий, заторов, потерю, подтверждение, вычисления времени жизни и прочую муть. Дык вот если Вы тут обшибётесь - то увы и ах, Вы потеряете много времени и образно - останетесь на бобах....Перед тем как писать - взгляните повнимательней на TCP протокол. Почитайте рекомендации от какой-нить юникс системы например...


с уважением
(круглый)

Карабас БарабасВы нам потом логи пришлите сюда

да нету логов...отозвалси я...в ответ тишина...видать бой где то :)


(круглый)