|
|
#1 
1nfallibLe.hardcOre @ 11.09.07 17:17 |
[пожаловаться]
|
|
Когда захожу в ГГЦ, мне выдаёт такое сообщение:
Error Connecting to server! Error Code: Error Code - 1233076453
|
|
|
|
#4
Walex @ 11.09.07 17:23 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP
|
|
|
|
#5
q[^.^]p @ 11.09.07 17:28 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP
|
|
|
|
#7
Reverant] @ 11.09.07 17:31 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP
|
|
|
|
#8
Time.Roni @ 11.09.07 17:31 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP
|
|
|
|
#14
JaM @ 11.09.07 17:53 |
[пожаловаться]
|
|
#13 +1 Я так каждое утро делаю.
З.Ы. #1 Сори, не знаю 
|
|
|
|
#19
x-master666 @ 11.09.07 18:31 |
[пожаловаться]
|
|
Автор ты не знал, что выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.
мда... автор, не ожидал...
|
|
|
|
#20
rAindAY @ 11.09.07 18:32 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP-Помойму у тебя это.
|
|
|
|
#21
Saytiev @ 11.09.07 18:34 |
[пожаловаться]
|
|
Ну как же так?? Даж Светка Букина знает, что Выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п. все четко и понятно!!!
|
|
|
|
#22
Ape1Sin4eg @ 11.09.07 18:34 |
[пожаловаться]
|
|
Выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.
|
|
|
|
#26
1nfallibLe.hardcOre @ 11.09.07 20:12 |
[пожаловаться]
|
|
Уахахаха)) Парни, вы меня реально насмешили..... и действительно как я сразу не догадался, ведь это так просто:
Выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п. все четко и понятно!!!
№25 А если у меня нет фаервола!?
|
|
|
|
#28
Reverant] @ 11.09.07 20:15 |
[пожаловаться]
|
|
У меня была такая же фигня и мой друг сказал, что выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п. все четко и понятно!!!
|
|
|
|
#29
S_T_A_L_K_E_R @ 11.09.07 20:28 |
[пожаловаться]
|
|
Ну не знаю у меня такой фигни не было но!выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.
|
|
|
|
#31
Властелин_Браблея_[Элита] @ 11.09.07 20:30 |
[пожаловаться]
|
|
Я щас, короче, звонил в министерство обороны, мне там сказали, что выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.
|
|
|
|
#32
minifisker @ 11.09.07 22:35 |
[пожаловаться]
|
|
блин а я думал что на канальном уровне биты группируются в наборы, называемые кадрами (frames). Канальный уровень обеспечивает корректность передачи каждого кадра, помещая специальную последовательность бит в начало и конец каждого кадра, чтобы отметить его, а также вычисляет контрольную сумму,суммируя все байты кадра определенным способом и добавляя контрольную сумму к кадру. Когда кадр приходит, получатель снова вычисляет контрольную сумму полученных данных и сравнивает результат с контрольной суммой из кадра. Если они совпадают, кадр считается правильным и принимается. Если же контрольные суммы не совпадают, то фиксируется ошибка.
В протоколах канального уровня, используемых в локальных сетях, заложена определенная структура связей между компьютерами и способы их адресации. Хотя канальный уровень и обеспечивает доставку кадра между любыми двумя узлами локальной сети, он это делает только в сети с совершенно определенной топологией связей, именно той топологией, для которой он был разработан. К таким типовым топологиям, поддерживаемым протоколами канального уровня локальных сетей, относятся общая шина, кольцо и звезда..
В локальных сетях протоколы канального уровня используются компьютерами, мостами, коммутаторами и маршрутизаторами. В компьютерах функции канального уровня реализуются совместными усилиями сетевых адаптеров и их драйверов.
В глобальных сетях, которые редко обладают регулярной топологией, канальный уровень обеспечивает обмен сообщениями между двумя соседними компьютерами, соединенными индивидуальной линией связи.
Таким образом канальный уровень обеспечивает создание, передачу и прием кадров данных; обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде.
|
|
|
|
#35
war1or @ 12.09.07 01:04 |
[пожаловаться]
|
|
Ну автор ты себя показал не с лучшей стороны. Мы тебя на 1 раз прощаем...А вообще эта прблемма решается прочтением ниже написаного :
выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п. все четко и понятно!!!
Как сказал черномырдин "Отродясь не было и вот опять."
|
|
|
|
#41
Bonifan. @ 13.09.07 16:05 |
[пожаловаться]
|
|
мне кажеца проблема в автоматизации физико-химического деструктуризатора, использующего инстурументальную базу колебательной спектроскопии, а также некоректной интерпритации данного эксперимента.Возможно выходом из ситуации послужит создание единой библиотеки данных по строению и колебательным спектрам подходящей не для всех классов программ , посколькоу число известных соединений приближаеца к десяти миллионам и далеко не для всех имеюца исследования их спекторов.для интерпритации современоого спектрального экспериментачасто необходим анализ интегрированных колебаний молекулярной системы некоторого предполагаемого сроения, требуущий наличия соответствующих сведений по молекулярным структурам атомизированных частиц взаимодействующих с молекулярными силовыми полями...
|
|
|
|
#44
v200 @ 14.09.07 11:13 |
[пожаловаться]
|
|
Ошибка ассинхронизации динамического обслуживания транспортного уровня стека TCP IP
|
|
|
| Reply | | | |
|
|
|
