Теми рефератів
> Реферати > Курсові роботи > Звіти з практики > Курсові проекти > Питання та відповіді > Ессе > Доклади > Учбові матеріали > Контрольні роботи > Методички > Лекції > Твори > Підручники > Статті Контакти
Реферати, твори, дипломи, практика » Курсовые проекты » Перспектіврие засоби передачі інформації

Реферат Перспектіврие засоби передачі інформації





ього протоколу намагалися врахувати якомога більше ситуацій, які можуть виникнути. Зараз діє версія 1.0 цього протоколу, і основні особливості, якими він має, в даний час такі:

1. SDP повинен дозволяти пошук служб за спеціальними атрибутам цих служб.
Наприклад, якщо є декілька принтерів, доступних через Bluetooth, то клієнт повинен мати можливість знайти саме той принтер, який йому потрібен. p> 2. SDP повинен дозволяти клієнту шукати служби по класу. Якщо трохи переробити попередній приклад, то якщо клієнту знадобиться принтер, то повинна бути можливість знайти саме пристрій друку, не знаючи про нього нічого іншого. p> 3. SDP повинен дозволяти переглядати служби без необхідності знати специфічні характеристики цих служб. Наприклад, якщо пристрій надає будь-яку послугу може управлятися тільки спеціальним програмним забезпеченням по якому-небудь дуже рідкісного або закритому протоколом, то для SPD це не буде проблемою, все одно можна буде отримати інформацію про доступність і назві служби. p> 4. SDP повинен надавати можливості для виявлення нових служб, які з'явились за час роботи. p> 5. SDP повинен надавати можливість дізнаватися, коли служба стає недоступною із за того, що клієнт вийшов за межі зв'язку, або з якої-небудь іншої причини. p> 6. SDP дозволяє службам, класам служб і атрибутам служб бути однозначно ідентифікованими. p> 7. SDP повинен дозволяти одному пристрою знаходити будь-яку службу на будь-якому іншому пристрої без звернення до третього пристрою. p> 8. SDP повинен підходити для використання пристроями за обмеженою функціональністю. Пам'ятаєте, ми говорили про холодильниках? Але ж це далеко не межа ... p> 9. SDP повинен дозволяти збільшувати кількість доступної інформації про службу. Це означає, що якщо служба вимагає докладного і об'ємного опису своїх можливостей, параметрів, обмежень тощо, то вся ця інформація не буде вивалюватися на всіх, хто просто запитає про доступності служби, а буде надана тільки тим, хто пильніше зацікавиться саме цією службою. p> 10. SDP повинен підтримувати використання проміжних кешуючих агентів для прискорення або підвищення ефективності процесу пошуку нових служб. Цей пункт який суперечить пункту 7, тому що використання третього пристрою можливо, але не обов'язково. p> 11. SDP повинен бути повністю незалежний від протоколів більш високого рівня, що використовуються Bluetooth з'єднанням. p> 12. SDP повинен працювати, коли в якості його транспортного протоколу використовується L2CAP. p> 13. SDP повинен дозволяти знаходити і використовувати служби, які забезпечують доступ до інших протоколах виявлення служб. Це дозволяє розширювати можливості системи, і використовувати служби та пристрої які не мають Bluetooth інтерфейсу. p> 14. SDP повинен підтримувати створення і визначення нових служб без необхідності централізовано реєструватися. br/>

Крім цього, є ряд речей, які поки що не входить SDP, але дуже можливо, що в наступних редакціях специфікації багато з них стануть обов'язковими. p> 1. SDP 1.0 не надає механізму доступу з службам, тільки інформацію про служби. p> 2. SDP 1.0 не надає можливості оцінювати служби. Тобто, з його допомогою не можна автоматично вибрати найбільш підходящу службу, якщо доступно відразу декілька служб надає схожий сервіс. p> 3. SDP 1.0 не дозволяє домовлятися про параметрах служби. p> 4. SDP 1.0 не дозволяє дізнатися про завантаженість служби, або пристрою надає службу. p> 5. SDP 1.0 не дає можливості клієнту управляти службою. p> 6. SDP 1.0 не дозволяє повідомляти про те, що служба або інформація про службу стає недоступною. p> 7. SDP 1.0 не дозволяє повідомляти про те, що атрибути служби змінилися. p> 8. В даний час специфікація не описує інтерфейсу, через який програми повинні звертатися до SDP. p> 9. SDP 1.0 в даний час не володіє розвиненим механізмом управління списком служб, наприклад

10. SDP 1.0 не дозволяє накопичувати і реєструвати служби.


Ще одним з протоколів, які використовують L2CAP в як транспортний є, RFCOMM. Цей протокол емулює з'єднання PPP (Point-to-point) по серійному порту (RS-232 або EIATIA-232-E, більш відомим як COM-порти). Через нього працює такі служби як, наприклад, LAN Access. Ця служба може працювати як емуляція Direct cable Connection, коли треба забезпечити зв'язок між всього двома PC, так і використовуватися для повноцінного входу у вже існуючу локальну мережу. У другому випадку використовується пристрій під назвою LAN Access point, через яке комп'ютер з Bluetooth виявляється, підключений до LAN так, як він міг би підключитися через dial-up з'єднання. p> TCS - Telephony Control protocol Specification ще одна служба, яка використовує L2CAP в якості транспортного протоколу. Ця служба може використовуватися центральної домашньої телефонної станцією для переадресування телефонних дзвінків. При цьому TCS використовується тільки для обслуговування з'єднання. Після ...


Назад | сторінка 10 з 16 | Наступна сторінка





Схожі реферати:

  • Реферат на тему: Що повинен знати упрощенщік, який продає товари з ПДВ за договором комісії
  • Реферат на тему: Учитель XXI століття. Яким він повинен бути ...
  • Реферат на тему: Яким повинен буті викладач
  • Реферат на тему: Взаємозв'язок державної цивільної служби та муніципальної служби
  • Реферат на тему: Муніципальна служба як особливий вид служби в системі місцевого самоврядува ...