SDP Temel Özellikleri

SDP Bluetooth cihazlarının uygun servisleri kendileri için ayırmalarını amaçlar. Bluetooth ağları LAN veya WAN gibi geleneksel ağlardan niteliksel olarak çok farklıdır. Cihazlar ve servisler Bluetooth pikonetlerine sık sık girip çıkarlar. SDP de bu tarzda çalıĢan ağ gereksinimleri için geliĢtirilmiĢtir.

SDP istemcinin fikrini (servis arayan birim) ve bir sunucuyu (servisleri sağlayan birim) içerir. Cihazlar kimi zaman istemci kimi zaman da sunucu olarak davranabilir. Servis sağlayıcı, sağladığı servisleri tanımlayan bir “servis kayıt” listesi tutmalıdır. Bu liste “servis kaydı” olarak adlandırılır. Bir servis kaydı spesifikasyon tarafından tanımlanan standart Ģekilde servisleri tanımlar. Servis kaydı servisin sınıfı ve özellikleri hakkında (yazma, faks gönderme, ses servisleri, bilgi servisleri gibi),

servis ile etkileĢecek protokol katmanları hakkında ve servis hakkında kiĢilerin bilgi edinmesini sağlayacak ek bilgiler gibi bölümler içerir. ġekil 4.34 de bir servis kaydının genel yapısı gösterilmiĢtir. Her biri bir servis kayıt eki (srvRecHnd[0] dan srvRecHnd[j] ye kadar) ve servis özelliği (srvAttribute[0:a] dan srvAttribute[j:c] ye kadar) ile gösterilen bir servis seti gösterilmiĢtir.

ġekil 4.34 SDP servis kaydının genel yapısı

Servis kayıtları hem genel servis özelliklerini hem de servise özel özellikleri içerir. Genel servis özellikleri tüm servis tiplerine uygulanan servis sınıfı ve protokol yığın bilgisi gibi bilgilerdir. Servise özel özellikler ise özel bir sınıf ya da bir servis durumu ile ilgili bilgilerdir. Servise özel özellik örnekleri bir yazma servisine özgü özellikler (renkli, dublex ve bitirme kapasitesi gibi), bir ses servisine özgü özellikler (veri hızı veya kodlama yapısı gibi) veya bir çevirmeli ağ servisine özgü servisler (seri port konfigürasyonu veya modem kurulum bilgisi gibi) Ģeklinde verilebilir. Servislere özgü özellikler Bluetooth profilleri içerisinde tanımlanmıĢtır. Profiller kullanım senaryolarını ve protokol yığınının kullanımını tanımlarlar. Örneğin kulaklık-mikrofon seti profili servise özgü olan “uzak ses kontrolü” özelliğini tanımlar. Genel servis özellikleri her tipteki servise uygulanabilir olmakla birlikte zorunlu değillerdir. Her servisin kendi servis kaydı içinde her genel servis özelliğini içermesi Ģart değildir. Sadece iki genel servis özelliği zorunludur: sınıfı veya servis tipini belirleyen servis sınıfı özelliği ve servis kaydını gösteren servis kayıt tanıtıcısı

srvRecHnd[0] srvAttribute[0:a]

attrName:attrValue

srvRecHnd[j] srvAttribute[j:c] srvRecHnd[i] srvAttribute[i:b]

]]

srvAttribute[0:a]

Searchable attribute (UUID) Servis

(handle). Servis kayıt tanıtıcısı (handle) istemci tarafından sunucunun servis kaydına ulaĢmak için kullanılır.

Bir servis kaydındaki her servis özelliği bir özellik belirleyici (özellik ID, 16-bitli iĢaretsiz bir tamsayıdır) ve o özellik belirleyici ile iliĢkili olan bir özellik değeri içerir. Her servis kayıt girdisi bu iki değeri içerir. Bu özellikler her türde bilgiyi tanımladıkları için, SDP özellik değeri için “veri elementi” kavramını kullanır. Veri elementi kendi kendine tanımlanan bir veri parçasıdır. Veri elementinin ilk kısmı verinin gerçek boyutu ve tipini belirten 1 byte lık baĢlık bilgisinden oluĢur. Veri elementinin geriye kalan kısmı da özellik ve format için olan veri değerlerini ve veri elementi baĢlığı tarafından belirlenen boyut bilgisini içerir. SDP veri elementlerini kullanarak, özellik değerlerinin string, Boolean, iĢaretli ve iĢaretsiz tamsayı ve genel tek belirleyiciler (universal unique identifier - UUID) gibi farklı Ģekillerde olmasına izin verir. Böylelikle birçok veri tipi için esnek bir sunum imkanı sağlanmıĢ olur. Bluetooth kablosuz haberleĢmesinde bir servisi keĢfetmek basit bir iĢleme dönüĢmüĢ olur: istemci ilgilendiği servisi ya da servisleri belirler, sunucu istemcinin talebine uygun olan servisleri belirterek cevap verir. Pratikte, istemci hangi servisleri aradığını belirten ve SDP protokolü veri ünitesi formatında (SDP_PDU) olan bir talep gönderir. Benzer Ģekilde sunucu da SDP_PDU formatında bir cevap gönderir. Bu süreci gerçekleĢtirmek için istemci ve sunucu talep ve cevaplarını belirtmek için standart bir metoda gereksinim duyarlar. Bu amaçla SDP UUID leri tanımlamıĢtır. Bir UUID, International Organization for Standardization (ISO) dan alınarak benimsenen bir kavramdır. UUID ler algoritmik olarak üretilebilen ve tek olan 128-bitlik değerlerdir. Hiçbir UUID daha önce üretilen bir UUID ile aynı değeri alamaz. UUID kullanmanın bir avantajı SIG mevcut profiller ile ilgili servislere iliĢkin “iyi bilinen” UUID lerin listesini yayınlamıĢ olmasına karĢın; yeni servisler için yeni tanımlayıcılar belirleme iĢleminin SIG tarafından sağlanan tanımlayıcılara merkezi bir kayıt iĢlemi gerektirmemesidir. Böylelikle bir servis arayan istemci servis arama talebinde sadece o servis sınıfı ya da özel servisle ilgili olan UUID yi belirtir; servis sağlayıcı da bu UUID yi uygun cevabı verecek Ģekilde eĢleĢtirir.

Ġstemci ile sunucu arasında değiĢ tokuĢ edilen SDP_PDU ları basit iletimlerdir. SDP protokol akıĢı genel olarak iki iletim gerektirir; spesifikasyon üç farklı SDP iletimi

tanımlar fakat üçüncüsü sadece ilk ikisinin karĢıtıdır. Tipik bir SDP iletimi aĢağıdaki bölümlerden oluĢur:

1. Ġstemci ilgilendiği servisleri aramak için bir talep gönderir; sunucu da bu talebe uygun gelen tanıtıcılar (handle) ile cevap verir.

2. Ġstemci ilgilendiği servislerle ilgili servis özellikleri hakkında ek bilgi almak için ilk adımda elde edilen tanıtıcıları (handle) kullanarak bir talep gönderir. Yukarıdaki iletimi takiben, istemci 2.adımda elde ettiği bilgiyi kullanarak SDP den farklı bazı protokoller kullanarak servise eriĢir ve faydalanır. 1.adım “Servis Arama” iletimi olarak adlandırılır ve istemciden sunucuya gönderilen Servis Arama Talebi SDP_PDU su ile sunucudan istemciye gönderilen Servis Arama Cevabı SDP_PDU sundan oluĢur. Servis Arama Cevabı SDP_PDU su talep ile eĢleĢen bir veya birden fazla tanıtıcı (handle) içerir. 2. adımda istemci bu tanıtıcıların (handle) bir veya birden fazlasını bir Servis Özellik Talebi SDP_PDU sunda kullanır, sunucu da bir Servis Özellik Cevabı SDP_PDU su oluĢturur. Bu değiĢ tokuĢ Servis Özellik iletimi olarak adlandırılır. Servis Özellik Cevabı SDP_PDU sunda istemcinin Servis Özellik Talebi SDP_PDU sunda belirlediği özellik ID lerine karĢılık gelen servislerle ilgili özellik değerleri bulunur. Bu özellikler genel servis özellikleri ile servislere özgü özelliklerin bir kombinasyonu Ģeklinde olabilir. Çoğu durumda istemciye servise sonradan bağlanmak için yeterli bilgi sağlar.

Bluetooth spesifikasyonu Servis Arama Özelliği adında üçüncü bir SDP iletimi tanımlar. Bu iletim Servis Arama Özellik Talebi SDP_PDU su ile Servis Arama Özellik Cevabı SDP_PDU sundan oluĢur. Bu iletim yukarıda açıklanan diğer iki iletime göre daha az gereklidir fakat verimlilik için kullanılmaktadır. Servis Arama Özellik iletiminin sağladığı Ģey 1. ve 2. adımların kombinasyonudur. Ġstemci tek bir taleple sadece servis talebinde bulunmakla kalmaz, sunucunun cevabındaki uygun servislerle ilgili özellikleri de talep etmiĢ olur. Sunucu da uygun servislerle ilgili tanıtıcıları (handle) ve bu uygun servislerin istenen özellik değerlerini de cevaplamıĢ olur. Bu sebeple uygulama geliĢtiricilerin SDP iletimleri için uygulanacak profile bağlı olmakla birlikte iki alternatifleri vardır. Daha önemlisi, Servis Arama Özellik iletimi bazı durumlarda hava arabirimi üzerinden iletilen byte miktarı gözönüne alındığında daha verimli sonuç verir. Konsolide olmuĢ iletimin kendisi tek tek yapılan iletimlere göre daha çok byte gerektirebilir fakat daha az sayıda toplam

iletim ile sonuç verir. Özellikle birçok servis kaydına eriĢilen bazı durumlarda, örneğin bir servis tarama (browsing) uygulamasında, Servis Arama Özellik iletimi daha verimli olabilir.

Bluetooth spesifikasyonu bir hata cevabı SDP_PDU su ve Devamlılık Durumu Ģeklinde adlandırılan bir mekanizma gibi özel durumlar için de protokol tanımlamaları içerir. Bu tanımlamalar tek bir SDP_PDU suna uymayan sunucu cevapları için kullanılır. Ġstemci kendi SDP_PDU suna karĢılık gelecek cevabın maksimum boyutunu belirleyebilir. Sunucunun cevabının bu boyuttan daha büyük olması mümkündür. Bu durumda, sunucu kendi cevabının sonuna bazı devamlılık durum bilgileri de ekleyerek istemcinin istediği takdirde cevabın devamı için tekrar talepte bulunmasını sağlar. Bazı durumlarda iletimin kendisi basit olmasına rağmen bu iletimler için yaratılan byte dizileri kompleks olabilir. Bu kompleks olma durumu özellikle SDP_PDU ları içinde kompleks veri elementleri taĢındığı zaman ortaya çıkar. SDP_PDU ları içinde bu tip kompleks veri tipleri bulunduğunda ya da devamlılık durum bilgisi kullanılarak SDP_PDU sunun bölünmesi gerektiğinde, SDP_PDU sunun her segmentindeki byte sayısını doğru olarak veren değiĢik “sayı” alanları oluĢur.

ġekil 4.35 SDP iletimlerini özetlemektedir. ġekilde gösterilen argüman ve parametreler SDP_PDU ları içinde geçen bazı argüman ve parametrelerdir. ġekil 4.34 ten de anlaĢılabileceği gibi adece UUID ler tarafından tanımlanan servisler ve servis özellikleri aranabilir (searchable) özelliktedir. UUID ler tarafından tanımlanmayan bir servisin özellikleri aranamaz (unsearchable) ve o servis ancak bir UUID özelliği kullanarak yerleĢtirildikten sonra alınabilir. [2,13]