Socket под Lan

[~Lexx~]

Не подскажете как грамотнее организовать передачу файла по сетке? - файл небольшой но качаеться часто - 4 раза в секунду - посоветуйте как лучше сделать - использовать Sock_stream, Sock_dgram или Sock_raw? обмен идет с приложением, которое должно работать под Nt... Буду очень благодарен за совет

[zythar]

на стороне сервера.
принимаем коннект. открываем файл. читаем из него. пишем в сокет.

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

юзать нужно имхо sock_stream. хотя от того что ты конкретно юзаешь алгоритм не меняется. меняются только функции (насколько я знаю для сокет типа sock_dgram используются другие функции) . прочитай про каждый из типа сокетов и сам реши что нужно использовать.

[~Lexx~]

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

[zythar]

хз.. я не сталкивался.. установи опытным путем ((*
попробуй сделать обеями способами ((*

[~Lexx~]

Ну видать придеться))) спасибо за совет)

[Delimiter]

использовать UDP вместо TCP можно , но не забывай что юдп не является протоколом гарантированной доставки. Пакеты могут теряться может даже измениться порядок их следования (на кривых роутерах) , поэтому то что делают ACQ и SEQ в тсп протоколе ты должен реализовать сам, либо прикручивать как это делается в p2p к каждому фрагменту заголовок говорящий в какое место файла идет данный блок.

удачи!
хотя если ты сможешь весь файл посылать одним UDP , то это будет "бескровное" решение.

[krypt3r]

А что, если вместе с файлом по удп отсылать его контрольную сумму? Хоть какая-то проверка на доставленность. Клиент просто проверяет вычисленную сумму полученного файла с суммой, пришедшей по удп от сервака. Если суммы равны, то все гуд, ежели нет, то...

[Delimiter]

да достоверности там и не могет быть..... не стремись получить ее, иначе придумаешь новый ТСР.
допустим в поле данных UDP есть твой собственный мини заголовок

[N фрагмента]данные

тогда

---> передача Id блока и количество фрагментов N
<--- подтверждение получения Id
---> передача пакета
--->
.......... в этом месте источник СТРЕЛЯЕТ N фрагментов как "из пушки"
--->
---> передача пакета
---> передача индентификатора конца блока
<--- блокid(-1) если все блоки дошли либо перечисление недошедших (2,28,39)
---> подтверждение корректировки
----------------------------------------------------------------И ПОВТОРЯЕТСЯ ПРИНЯТИЕ ПАКЕТОВ!!!
в любом случае если хочешь не утратить скорости UDP своди все на "бескотрольную" передачу UDP



по поводу контрольной суммы..... если ты отсылаешь пакет(файл одним пакетом) и он доходит ТО НЕ НУЖНО ПРОВЕРЯТЬ в целостности он или нет!!!! В спецификации UDP нет понятия фрагментации которая может "резануть" пакет (это чиста фича ТСР)

[~Lexx~]

В общем заработало - стал передавать сплошным потоком - сэкономил 3% трафика - этого мне хватило)) спасибо за советы.

[~Lexx~]

по поводу контрольной суммы..... если ты отсылаешь пакет(файл одним пакетом) и он доходит ТО НЕ НУЖНО ПРОВЕРЯТЬ в целостности он или нет!!!! В спецификации UDP нет понятия фрагментации которая может "резануть" пакет (это чиста фича ТСР)

Прости что ты имешь в виду? Насколько я знаю udp дейтаграмма содержит в своем заголовке чексумму.

[Delimiter]

я говорил что не нужно проверять ничего..... было предложено создавать контрольную сумму. А раз создание (самопальной) то и проверка подразумевается!

:D Ну не проверять же контрольную сумму созданную винсок_длл-кой....для такой же длл-ки на другом конце???


кстати если странно что такое малое преимущество в ТРАФИКЕ данных получил..... такое может быть только при миллюзерном файле!

[~Lexx~]

у меня файл был 1.5- 2 кб))) он просто качался не меньше 4 раз за секунду)

[Delimiter]

одним пакетом слал?

Сэкономил
2*size(SYN)+2*size(RST)+(size(TCP_header)-size(UDP_header))+65
65-байт пакет подтверждения "оконной" сессии

[~Lexx~]

Угу

[nc.STRIEM]

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

[~Lexx~]

у меня файл генериться 4-6 раз в секунду в нем содержиться инфа с нескольких датчиков. До этого файл писался на диск и оттуда качался по самбе)))) До меня это всех устраивало. Но у мну курсач -параллельная обработка нескольких сетевых ус-в. ну и сообтветсвенно пришлось усовершенствовать отправку. Я может немного не коректно выразился - как таковой этот файл теперь не создаетсья - я создаю пакет, шифрую его и передаю. К сожалению не имею права открыть исходники...