Bluetooth и сокеты

[LMnet]

Здравствуйте. Пишу бакалаврскую с использованием C++ MFC. Программирую смартфон под Windows Mobile. Задача такая: передать некоторые данные от модема неподалеку к смартфона по блютусу. Данные - последовательность бит неопределенной длины. Блютус реализую при помощи сокетов. На данный момент написал класс CBluetoothSocket, который унаследовал от CAsyncSocket (хотя сейчас уже сомневаюсь в правильности решения, подумываю использовать CSocket). Написал парсер для разбора входного пакета данных.
Это все было предисловием Теперь то, что я собственно хотел узнать. Протокол bluetooth подразумевает пакетную передачу данных, причем информационное поле пакета имеет длину 0-2745 бит. Те данные, которые передаю я, врядли будут иметь такой маленький размер, то есть в один пакет не уместятся. Передаваемый пакет разобьется на части и будет передаваться по блютусу. Например, мой пакет разделится на 4 части. На приемной стороне (смартфон) будет автоматом вызываться матод OnReceive когда в приемном буфере будут какие-то данные. Но мне не ясно, OnReceive вызовется уже после того, как все 4 части моего большого пакета передадуться, либо OnReceive будет вызываться каждый раз, как приходит маленький пакет? Первый вариант подразумевает, что склеивать большой пакет мне не нужно, а во втором случае мне нужно будет руками соединять их в один большой пакет. Вроде из литературы я понял, что все должно делаться автоматом еще на уровне протокола, но все-таки я не уверен.
И еще хотел спросить, какая практическая разница в CAsyncSocket и CSocket? Я так понял, что в CSocket решена проблема блокирования и еще ряд других и с ним проще работать. Но мне нужно, чтобы вся передача была в фоне, могу ли я использовать в таком случае CSocket?
Еще было бы очень хорошо найти того, кто имеет опыт в программировании bluetooth под MFC, или хотя бы получить ссылку куда-нибудь, информации об этом довольно мало, а уж тем более на русском.

[veniside]

> Вроде из литературы я понял, что все должно делаться автоматом еще на уровне протокола

срочно сожгите такую литературу.

> Протокол bluetooth подразумевает пакетную передачу данных

блютус тут побоку, пакетную передачу данных требует IP протокол. TCP (у вас же не UDP сокеты, верно?) сделает за вас часть работы, но только часть. Разбирать, где начало и где конец передачи, надо будет самому (если за одно подключение могут быть переданы несколько разных не связанных блоков данных/файлов).

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

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

[LMnet]

Сообщение от veniside

> Вроде из литературы я понял, что все должно делаться автоматом еще на уровне протокола

срочно сожгите такую литературу.

Да тут скорее всего дело не в литературе, а во мне. Прямо об этом нигде не сказано, поэтому я и спрашиваю.

Сообщение от veniside

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

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

А если использовать не асинхронный сокет а CSocket ситуация аналогична?

Я так понимаю, мне придется вводить дополнительные стартовые и стоповые биты в пакет данных для контроля за передачей. В bluetooth имеется режим эмуляции COM порта. Руководитель мне говорил, что там имеется встроенный механизм контроля начала и конца передачи. Получается, мне лучше именно такой режим применить?

[veniside]

> Так все-таки мне нужно самому соединять куски данных?

ну, возможно ваши 4 пакета и сольются в каком-нибудь буфере на клиенте, и OnReceive таки вызовется 1 раз. Но особо рассчитавать на это я бы не стал. Тем более, если завтра у вас размер данных увеличится (фильм закачать на 700 МБ потребуется), не будете же вы переписывать программу.

> Я так понимаю, мне придется вводить дополнительные стартовые и стоповые биты в пакет данных для контроля за передачей.

угу, вероятно. Обычно, каждый блок данных предваряют заголовком, в котором описывается как минимум длина передаваемых данных. Опять же, если у вас соединение закрывается сразу после успешной передачи блока данных (файла), а новый блок посылает путём создания нового соединения, можно этого и не делать.

> В bluetooth имеется режим эмуляции COM порта. Руководитель мне говорил, что там имеется встроенный механизм контроля начала и конца передачи. Получается, мне лучше именно такой режим применить?

скорей всего это все не имеет ни малейшего отношения к сокетам.

[LMnet]

Сообщение от veniside

Обычно, каждый блок данных предваряют заголовком, в котором описывается как минимум длина передаваемых данных.

Этот заголовок я ввожу сам, или это тот заголовок, который генерируется протоколом bluetooth? Если первое то понятно, придется добавить кое-то в пакет. Если второе, то возникает такой вопрос про Receive: этот метод возвращает только данные, либо данные+служебная информация (в случае блютуса это код доступа и заголовок). Вроде бы Receive должен возвращать только данные, а обработка всей служебной информации ведется внутри программы.

Сообщение от veniside

Опять же, если у вас соединение закрывается сразу после успешной передачи блока данных (файла), а новый блок посылает путём создания нового соединения, можно этого и не делать.

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

[veniside]

> Этот заголовок я ввожу сам

да, сами. Ведь TCP — это просто поток. Что на одной стороне послали, то на другой получили. Но нет гарантии, что получим ровно теми же кусками, что были посланы. например, послали 10000 байт, а получатель принял блоки по 2048, 2048, 2048, 2000 и 1856 байт. Единственное, что гарантирует ТCP — что данные будут доставленны в том же порядке, и без потерь.

> соединение открывается с началом программы и открыто постоянно

тогда без своего протокола не обойтись, т.к. вам нужно будет понимать, где конец одной передачи и начало другой. Свой протокол == заголовок перед передачей нового блока данных (файла).

[LMnet]

veniside, спасибо большое за советы! Вы мне очень помогли А вы случаем не знаете ответ на мой последний вопрос из первого поста (про CAsyncSocket и CSocket)?

[veniside]

> CAsyncSocket и CSocket?

судя по именам классов, CSocket относится к блокирующим сокетам, а CAsyncSocket к неблокирующим (с мфс-шными сокетам не работал, можно глянуть в мсдн). Оба класса применимы для работы в фоновом режиме. Просто для CSocket вам нужно будет самому создать новый поток, и в нём работать с блокирующим сокетом (т.е. сокетом, вызов send() или receive() у которого может "зависнуть" на неопределенное время). Для CAsyncSocket дополнительный поток, скорей всего, не понадобится, но надо быть готовым к тому, что его события могут быть вызваны в любой (неподходящий) момент из служебного потока. Что лучше — дело привычки.