Не подскажете как грамотнее организовать передачу файла по сетке? - файл небольшой но качаеться часто - 4 раза в секунду - посоветуйте как лучше сделать - использовать Sock_stream, Sock_dgram или Sock_raw? обмен идет с приложением, которое должно работать под Nt... Буду очень благодарен за совет
на стороне сервера. принимаем коннект. открываем файл. читаем из него. пишем в сокет. на стороне клиента. устанавливаем соединение. принимаем данные. создаем файл. пишем в него данные. юзать нужно имхо sock_stream. хотя от того что ты конкретно юзаешь алгоритм не меняется. меняются только функции (насколько я знаю для сокет типа sock_dgram используются другие функции) . прочитай про каждый из типа сокетов и сам реши что нужно использовать.
да функции изменяться - все это я уже разобрал. Другое дело - прога написанна -и она работает, просто нехватает канала... чуть чуть не хватает))) так вот я использовал sock_dgram... вот и подумалось мне не попробовать ли мне передавать сплошным потоком - не будет ли так меньше жрать канала? мот кто сталкивался с таким?
использовать UDP вместо TCP можно , но не забывай что юдп не является протоколом гарантированной доставки. Пакеты могут теряться может даже измениться порядок их следования (на кривых роутерах) , поэтому то что делают ACQ и SEQ в тсп протоколе ты должен реализовать сам, либо прикручивать как это делается в p2p к каждому фрагменту заголовок говорящий в какое место файла идет данный блок. удачи! хотя если ты сможешь весь файл посылать одним UDP , то это будет "бескровное" решение.
А что, если вместе с файлом по удп отсылать его контрольную сумму? Хоть какая-то проверка на доставленность. Клиент просто проверяет вычисленную сумму полученного файла с суммой, пришедшей по удп от сервака. Если суммы равны, то все гуд, ежели нет, то...
да достоверности там и не могет быть..... не стремись получить ее, иначе придумаешь новый ТСР. допустим в поле данных UDP есть твой собственный мини заголовок [N фрагмента]данные тогда ---> передача Id блока и количество фрагментов N <--- подтверждение получения Id ---> передача пакета ---> .......... в этом месте источник СТРЕЛЯЕТ N фрагментов как "из пушки" ---> ---> передача пакета ---> передача индентификатора конца блока <--- блокid(-1) если все блоки дошли либо перечисление недошедших (2,28,39) ---> подтверждение корректировки ----------------------------------------------------------------И ПОВТОРЯЕТСЯ ПРИНЯТИЕ ПАКЕТОВ!!! в любом случае если хочешь не утратить скорости UDP своди все на "бескотрольную" передачу UDP по поводу контрольной суммы..... если ты отсылаешь пакет(файл одним пакетом) и он доходит ТО НЕ НУЖНО ПРОВЕРЯТЬ в целостности он или нет!!!! В спецификации UDP нет понятия фрагментации которая может "резануть" пакет (это чиста фича ТСР)
В общем заработало - стал передавать сплошным потоком - сэкономил 3% трафика - этого мне хватило)) спасибо за советы.
я говорил что не нужно проверять ничего..... было предложено создавать контрольную сумму. А раз создание (самопальной) то и проверка подразумевается! Ну не проверять же контрольную сумму созданную винсок_длл-кой....для такой же длл-ки на другом конце??? кстати если странно что такое малое преимущество в ТРАФИКЕ данных получил..... такое может быть только при миллюзерном файле!
одним пакетом слал? Сэкономил 2*size(SYN)+2*size(RST)+(size(TCP_header)-size(UDP_header))+65 65-байт пакет подтверждения "оконной" сессии
есле файл небольшой то есть смысл при старте программы загружать его в память и оттуда каждый раз отправлять, а не читать с диска
у меня файл генериться 4-6 раз в секунду в нем содержиться инфа с нескольких датчиков. До этого файл писался на диск и оттуда качался по самбе)))) До меня это всех устраивало. Но у мну курсач -параллельная обработка нескольких сетевых ус-в. ну и сообтветсвенно пришлось усовершенствовать отправку. Я может немного не коректно выразился - как таковой этот файл теперь не создаетсья - я создаю пакет, шифрую его и передаю. К сожалению не имею права открыть исходники...