BLE մանրադիտակի տակ (ATTы GATTы…)
Մաս 1, ակնարկ
Արդեն բավական երկար ժամանակ է անցել այն պահից, երբ թողարկվել է Bluetooth 4.0-ի առաջին սպեցիֆիկացիա: Եվ, չնայած BLE թեման շատ հետաքրքիր է, այն դեռ հետաձգում է շատ մշակողների՝ իր բարդության պատճառով: Իմ նախորդ հոդվածներում ես հիմնականում նայում էի ամենացածր մակարդակին՝ Link Layer-ին և Physical Layer-ին: Սա թույլ տվեց մեզ խուսափել այնպիսի բարդ և շփոթեցնող հասկացություններից, ինչպիսիք են Հատկանիշի արձանագրությունը (ATT) և Ընդհանուր հատկանիշի պրոֆիլը (GATT): Այնուամենայնիվ, գնալու տեղ չկա, առանց դրանք հասկանալու, անհնար է համատեղելի սարքեր մշակել: Այսօր ես կցանկանայի կիսվել ձեզ հետ այս գիտելիքներով: Իմ հոդվածում ես հիմնվելու եմ սկսնակների համար Nordic կայքից: Այսպիսով, եկեք սկսենք:
Ինչու՞ է ամեն ինչ այդքան դժվար:
Իմ կարծիքով, անմիջապես պարզ դարձավ, որ սմարթֆոնների միջոցով սարքերի կառավարումը շատ խոստումնալից և երկարատև թեմա է։ Ուստի որոշեցին այն կառուցապատել անմիջապես և առավելագույնը։ Որպեսզի տարբեր գաջեթների արտադրողները չմտածեն իրենց սեփական արձանագրությունները, որոնք հետո անհամատեղելի կլինեն։ Այստեղից էլ դժվարությունը. Արդեն առաջին փուլում նրանք փորձեցին ամեն ինչ սեղմել BLE արձանագրության մեջ։ Եվ կարևոր չէ՝ այն հետագայում օգտակար կլինի, թե ոչ։ Բացի այդ, նրանք նախատեսում էին ապագա սարքերի ցանկի ընդլայնման հնարավորություն։
Եկեք նայենք նկարին, որտեղ գծված է BLE արձանագրության դիագրամը: Այն բաղկացած է մի քանի շերտերից։ Ամենացածր, ֆիզիկական շերտը (PHY) պատասխանատու է սարքի ռադիոալիքի համար: Հղման շերտը (LL) պարունակում է բայթերի ամբողջ հաջորդականությունը փոխանցված հաղորդագրության մեջ: Նախորդ հոդվածներում մենք ուսումնասիրել ենք հենց սա: Host Controller Interface-ը (HCI) փոխանակման արձանագրություն է BLE շերտերի կամ չիպերի միջև, եթե Controller-ը և Host-ը ներդրված են տարբեր չիպերի վրա: Logical Link Control and Adaptation Protocol (L2CAP) պատասխանատու է փաթեթների ձևավորման, շրջանակի, սխալների վերահսկման և փաթեթների հավաքման համար: Անվտանգության կառավարչի արձանագրությունը (SMP) պատասխանատու է փաթեթների կոդավորման համար: Ընդհանուր հասանելիության պրոֆիլը (GAP) պատասխանատու է սարքերի միջև տվյալների նախնական փոխանակման համար՝ որոշելու «Ով ով է»: Այն ներառում է նաև սկանավորում և գովազդ: Այս հոդվածում ես կկենտրոնանամ արձանագրության մնացած երկու մասերի վրա՝ GATT և ATT: GATT-ը ATT-ի վերին կառուցվածքն է, ուստի դրանք սերտորեն փոխկապակցված են:
Պատմությունը պարզեցնելու համար ես կցանկանայի դիմել անալոգիայի: Ես դա ինչ-որ տեղ լսել եմ և կցանկանայի աջակցել դրան: BLE սարքը պատկերացրեք որպես մի քանի դարակներով գրապահարան: Յուրաքանչյուր դարակ առանձին թեմա է: Օրինակ, մենք ունենք դարակներ գիտաֆանտաստիկայի, մաթեմատիկայի և հանրագիտարաններով: Յուրաքանչյուր դարակում կան գրքեր՝ նշված թեմայով: Իսկ որոշ գրքեր նույնիսկ ունեն թղթային էջանիշեր՝ նշումներով: Բացի այդ, մենք ունենք բոլոր գրքերի փոքրիկ թղթային կատալոգ: Եթե հիշում եք, դպրոցական գրադարանները թղթե բացիկներով նեղ տուփ են: Այս անալոգիայով կաբինետը մեր սարքի պրոֆիլն է: Դարակները ծառայություններ են, գրքերը՝ բնութագրեր, իսկ կատալոգը՝ ատրիբուտների աղյուսակ: Գրքերի էջանիշները նկարագրիչներ են, որոնց մասին ես նույնպես ավելի մանրամասն կխոսեմ ավելի ուշ:
Յուրաքանչյուր ոք, ով մշակել է սարքեր, գիտի, որ շատ նախագծեր ունեն նմանատիպ կոդ: Փաստն այն է, որ շատ սարքեր ունեն նմանատիպ ֆունկցիոնալություն: Օրինակ, եթե սարքերը սնուցվում են մարտկոցներով, ապա դրանց մակարդակը լիցքավորելու և վերահսկելու խնդիրը նույնն է լինելու։ Նույնը վերաբերում է սենսորներին: Փաստորեն, ծրագրավորման օբյեկտի վրա հիմնված մոտեցում «ապահովում է օբյեկտներ ստեղծելու ունակություն, որոնք համատեղում են հատկությունները և վարքագիծը ինքնուրույն միության մեջ, որը կարող է այնուհետև նորից օգտագործվել»:. Իմ կարծիքով, BLE-ն փորձեց նմանատիպ մոտեցում: Պրոֆիլները մշակվել են Bluetooth Special Interest Group (SIG) կողմից: Տարբեր արտադրողների սարքերը, որոնք ունեն նույն պրոֆիլները, պետք է առանց դժվարության աշխատեն միմյանց հետ: Պրոֆիլներն իրենց հերթին բաղկացած են ծառայություններից և բնութագրերի ծառայություններից՝ լրացված նկարագրիչներով: Ընդհանուր առմամբ, այն կարող է այսպիսի տեսք ունենալ.
Օրինակ, հաշվի առեք սրտի բաբախյունի մոնիտորի պրոֆիլի դիագրամը (ֆիթնես ապարանջան): Այն բաղկացած է երկու ծառայություններից և մի քանի բնութագրերից։ Դրանից անմիջապես պարզ է դառնում պրոֆիլի հիերարխիան: Անցակետի բնութագրիչը զրոյացնում է կալորիականության ծախսերի ընդհանուր քանակը:
1. Սրտի հաճախականության ծառայությունը ներառում է երեք հատկանիշ (0x180D).
ա) Պարտադիր սրտի հաճախության բնութագրիչ (0x2A37)
բ) Մարմնի ցուցիչի կամայական դիրքի բնութագիրը (0x2A38)
գ) Սրտի զարկերի վերահսկման կետի պայմանական բնութագրերը (0x2A39)
2. Մարտկոցի սպասարկում (0x180F):
ա) մարտկոցի լիցքավորման մակարդակի պարտադիր բնութագրիչ (0x2A19)
UUID
Որպեսզի մենք եզակիորեն մուտք գործենք պրոֆիլի տարրեր (ծառայություններ, բնութագրիչներ և նկարագրիչներ), մենք պետք է ինչ-որ կերպ համարակալենք դրանք: Այդ նպատակով ներդրվում է այնպիսի հասկացություն, ինչպիսին է Universally Unique ID (UUID) կամ Universally Unique Identifier: UUID-ը նշված է յուրաքանչյուր տողի փակագծերում: Եվ այստեղ կա մեկ յուրահատկություն. UUID-ի համար մենք որոշեցինք օգտագործել 16 և 128 բիթ երկարությամբ ծածկագիր: Ինչու ես հարցնում? BLE արձանագրությունում ամեն ինչ վերաբերում է էներգիայի պահպանմանը: Հետևաբար, 16 բիթների չափը բավականին խելամիտ է: Դժվար թե մոտ ապագայում ստեղծվի ավելի քան 65 հազ. եզակի ծառայություններ և առանձնահատկություններ: Այս պահին այն ամենը, ինչ նրանք կարող էին արդեն հաշվել (հիշեք, թե որտեղից է սա եկել. «նա ձեզ էլ է հաշվել» :-)) Համարակալված տարրեր , , и կարող եք դիտել հղումները:
Այնուամենայնիվ, կարծում եմ, բոլորը հիշում են ինտերնետում 4 բայթ IP հասցեների պատմությունը: Սկզբում կարծում էինք, որ դա բավական է, բայց հիմա դեռ չենք կարող անցնել 6 բայթանոց հասցեի։ Որպեսզի չկրկնվի այս սխալը և ազատություն տա DIYers-ի զվարճալի ձեռքերին, SIG-ն անմիջապես որոշեց ներմուծել 128-բիթանոց UUID-ներ: Սա անձամբ ինձ հիշեցնում է չլիցենզավորված 433 ՄՀց տիրույթը, որը տրվել է բոլոր տեսակի Կուլիբիներին ռադիոալիքից: Մեր դեպքում մշակվել է ծառայությունների և բնութագրերի 128-բիթանոց նույնացուցիչ: Սա նշանակում է, որ մենք մեր ծառայությունների և սարքերի համար կարող ենք օգտագործել գրեթե ցանկացած 128-բիթանոց արժեք: Միևնույն է, նույն UUID-ով հանդես գալու հավանականությունը ձգտում է զրոյի:
Փաստորեն, կարճ 16-բիթանոց UUID-ներն ունեն իրենց ընդլայնումը մինչև 128-բիթանոց արժեք: Հստակեցման մեջ այս ընդլայնումը կոչվում է Bluetooth Base UUID և ունի 00000000-0000-1000-8000-00805F9B34FB արժեքը: Եթե, օրինակ, 16-բիթանոց UUID հատկանիշն ունի 0x1234 արժեքը, ապա համարժեք 128-բիթանոց UUID-ն կունենա 00001234-0000-1000-8000-00805F9B34FB արժեքը: Եվ նույնիսկ տրված է համապատասխան բանաձեւը.
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Ես չգիտեմ, թե որտեղից է այս կախարդական թիվը: Եթե ընթերցողներից որևէ մեկը գիտի, թող գրի մեկնաբանություններում (Sinopteek մականունով օգտատերը դա արդեն արել է։ Տես մեկնաբանություններում)։ Ինչ վերաբերում է 128-բիթանոց UUID-ներին, ապա սկզբունքորեն կարող եք օգտագործել հատուկ ով դա կանի քո փոխարեն:
ATTY GATTy...
Փաստորեն, այդ ժամանակ զվարճանքը սկսվում է: Հիշեցնեմ, որ ATT-ն հիմնված է հաճախորդ-սերվեր հարաբերությունների վրա։ Այժմ մենք նայում ենք սերվերի սարքին: Այն պարունակում է այնպիսի տեղեկություններ, ինչպիսիք են սենսորների արժեքները, լույսի անջատիչի կարգավիճակը, գտնվելու վայրի տվյալները և այլն: Այժմ, երբ «մեր շքերթի բոլոր մասնակիցները» համարակալված են, մենք պետք է ինչ-որ կերպ դրանք տեղադրենք սարքի հիշողության մեջ: Դա անելու համար մենք դրանք դնում ենք աղյուսակի մեջ, որը կոչվում է ատրիբուտների աղյուսակ: Սա լավ հիշեք. Սա հենց BLE-ի սիրտն է: Սա այն է, ինչ մենք կքննարկենք հետագա: Այժմ մենք յուրաքանչյուր տող կկոչենք հատկանիշ: Այս աղյուսակը գտնվում է կույտի խորքում և, որպես կանոն, մենք ուղղակի մուտք չունենք դրան: Մենք սկզբնավորում ենք այն և մուտք ենք գործում այն, բայց այն, ինչ տեղի է ունենում ներսում, թաքնված է մեզանից յոթ կնիքների հետևում:
Եկեք նայենք նկարին ճշգրտումից, բայց մինչ այդ ես կցանկանայի անմիջապես ուշադրություն հրավիրել տերմինների հաճախակի շփոթության վրա, մասնավորապես, նկարագրիչների: Նկարագրողի դերը բնութագրիչի նկարագրությունը լրացնելն է: Երբ անհրաժեշտ է ընդլայնել նրա հնարավորությունները, ապա օգտագործվում են նկարագրիչներ։ Դրանք նաև ատրիբուտներ են, և ինչպես ծառայություններն ու բնութագրերը, դրանք գտնվում են ատրիբուտների աղյուսակում: Դրանք մանրամասն կքննարկենք հոդվածի երկրորդ մասում։ Այնուամենայնիվ, երբեմն նկարագրիչները վերաբերում են ատրիբուտների աղյուսակում տողի համարին: Սա պետք է նկատի ունենալ: Շփոթությունից խուսափելու համար մենք կօգտագործենք «հատկանիշի ցուցիչ» տերմինը այս նպատակների համար:
Այսպիսով, հատկանիշը դիսկրետ արժեք է, որն ունի իր հետ կապված հետևյալ հատկությունները.
1. Attribute Handle-ը հատկանիշին համապատասխանող աղյուսակի ինդեքսն է
2. Հատկանիշի տեսակը UUID է, որը նկարագրում է իր տեսակը
3. Հատկանիշի արժեքն այն տվյալն է, որը ինդեքսավորվում է հատկանիշի ցուցիչով
4. Հատկանիշների թույլտվությունները հատկանիշի այն մասն են, թույլտվությունները, որոնք չեն կարող կարդալ կամ գրվել՝ օգտագործելով հատկանիշի արձանագրությունը:
Ինչպե՞ս հասկանալ այս ամենը։ Ատրիբուտի ցուցիչը, համեմատաբար ասած, նրա համարն է մեր աղյուսակում:
Այն թույլ է տալիս հաճախորդին հղում կատարել որևէ հատկանիշի կարդալու կամ գրելու հարցումներում: Մենք կարող ենք համարակալել մեր տողերը (ատրիբուտները) 0x0001-ից մինչև 0xFFFF: Գրապահարանի հետ մեր համագործակցության մեջ սա թղթային կատալոգի քարտի համարն է: Նմանապես, ինչպես գրադարանի կատալոգում, քարտերը դասավորված են քանակի աճող կարգով: Յուրաքանչյուր հաջորդ տողի թիվը պետք է ավելի մեծ լինի, քան նախորդը: Ինչպես գրադարանում, երբեմն որոշ քարտեր կորչում են, այնպես որ մեզ մոտ կարող են բացեր լինել տողերի համարակալման մեջ: Սա թույլատրված է։ Գլխավորն այն է, որ դրանք առաջադիմական են գնում։
Ատրիբուտի տեսակը որոշում է, թե ինչ է ներկայացնում հատկանիշը: C լեզվի անալոգիայով,
որտեղ կան բուլյան, թվային փոփոխականներ և տողեր, այնպես որ այստեղ է: Ըստ հատկանիշի տեսակի մենք ճանաչում ենք
ինչի հետ գործ ունենք և ինչպես կարող ենք շարունակել աշխատել այս հատկանիշի հետ: Ստորև մենք կանդրադառնանք ատրիբուտների որոշ տեսակների: Օրինակ՝ «ծառայության հայտարարագիր» (0x2800), «բնութագրական հայտարարագիր» (0x2803), «նկարագրիչի հայտարարագիր» (0x2902):
Հատկանիշի արժեքը նրա իրական իմաստն է, ներեցեք տավտոլոգիան: Եթե հատկանիշի տեսակը տող է, ապա հատկանիշի արժեքը կարող է լինել, օրինակ, «Բարև աշխարհ !!!» կարգախոսը: Եթե հատկանիշի տեսակը «ծառայության հռչակագիր» է, ապա դրա արժեքը հենց ծառայությունն է: Եվ երբեմն սա տեղեկատվություն է այն մասին, թե որտեղ կարելի է գտնել այլ հատկանիշներ և դրանց հատկությունները:
Հատկանիշների թույլտվությունները սերվերին թույլ են տալիս հասկանալ, թե արդյոք թույլատրված է կարդալու կամ գրելու մուտքը:
Նկատի ունեցեք, որ այս թույլտվությունները վերաբերում են միայն հատկանիշի արժեքին, այլ ոչ թե բուն ցուցիչին, տեսակին կամ թույլտվության դաշտին: Նրանք. եթե հատկանիշի ձայնագրումը թույլատրված է, ապա մենք կարող ենք փոխել, օրինակ, «Բարև աշխարհ !!!» տողը: «Բարի լույս» տողին: Բայց մենք չենք կարող արգելել նոր տող գրել կամ փոխել հատկանիշի տեսակը և տողը նշել որպես «ծառայության հայտարարագիր»: Երբ հաճախորդը կապվում է սերվերի հետ, հաճախորդը պահանջում է դրա հատկանիշները: Սա թույլ է տալիս հաճախորդին իմանալ, թե ինչ կարող է տրամադրել սերվերը: Չնայած պետք չէ արժեքները կարդալ ու գրել։
Ինչն է նման
GATT-ի հայեցակարգը ատրիբուտները ատրիբուտների աղյուսակում խմբավորելն է շատ կոնկրետ և տրամաբանական հերթականությամբ: Եկեք ավելի սերտ նայենք ստորև բերված սրտի զարկերի պրոֆիլին: Այս աղյուսակի ամենաձախ սյունակը կամընտիր է: Այն մեզ ուղղակի նկարագրում է, թե ինչ է իրենից ներկայացնում այս տողը (հատկանիշը): Մյուս բոլոր սյունակները մեզ արդեն ծանոթ են։
Յուրաքանչյուր խմբի վերևում մենք միշտ ունենք ծառայության հայտարարագրի հատկանիշ: Դրա տեսակը միշտ 0x2800 է, և ցուցիչը կախված է նրանից, թե քանի հատկանիշ կա աղյուսակում: Նրա թույլտվությունները միշտ միայն կարդալու են՝ առանց որևէ իսկորոշման կամ թույլտվության: Այս հասկացությունների մասին մենք կխոսենք մի փոքր ուշ: Արժեքը ևս մեկ UUID է, որը ցույց է տալիս, թե որն է ծառայությունը: Աղյուսակում արժեքը 0x180D է, որը սահմանվում է Bluetooth SIG-ի կողմից որպես սրտի բաբախման ծառայություն:
Ծառայության հայտարարությունից հետո գալիս է բնութագրի հայտարարությունը: Այն իր ձևով նման է ծառայության հայտարարագրի: Նրա UUID-ը միշտ 0x2803 է, և նրա թույլտվությունները միշտ միայն կարդալու են՝ առանց որևէ իսկորոշման կամ թույլտվության: Եկեք նայենք Attribute Value դաշտը, որը ներառում է որոշ տվյալներ: Այն միշտ պարունակում է ցուցիչ, UUID և մի շարք հատկություններ: Այս երեք տարրերը նկարագրում են բնութագրիչ արժեքի հետագա հայտարարությունը: Սլաքը բնականաբար նշանակում է հատկանիշի աղյուսակում բնորոշ արժեքի հայտարարագրման վայրը: UUID-ն նկարագրում է, թե ինչպիսի տեղեկատվություն կամ արժեք կարող ենք ակնկալել: Օրինակ, ջերմաստիճանի արժեքը, լույսի անջատիչի վիճակը կամ որևէ այլ կամայական արժեք: Եվ վերջապես հատկությունները, որոնք նկարագրում են, թե ինչպես կարելի է փոխազդել բնորոշ արժեքի հետ:
Այստեղ մեզ սպասում է ևս մեկ որոգայթ. Այն կապված է հատկանիշի թույլտվությունների և բնորոշ հատկությունների հետ: Եկեք նայենք բիթային դաշտի հատկությունների նկարը ճշգրտումից:
Ինչպես տեսնում եք, այստեղ կան նաև դաշտեր, որոնք ապահովում են կարդալու և գրելու հնարավորություններ: Դուք կարող եք մտածել, թե ինչու ենք մենք կարդալ/գրելու թույլտվություններ հատկանիշի և սեփականության համար
կարդալ/գրե՞լ բնորոշ արժեքի համար: Մի՞թե նրանք չպետք է միշտ նույնը լինեն։ Փաստն այն է, որ բնութագրական արժեքի հատկությունները իրականում միայն առաջարկություններ են հաճախորդի համար, որոնք օգտագործվում են GATT-ում և կիրառական շերտերում: Սրանք պարզապես ակնարկներ են այն մասին, թե հաճախորդը ինչ կարող է ակնկալել բնութագրական հայտարարագրման հատկանիշից: Դիտարկենք սա ավելի մանրամասն: Ի՞նչ տեսակի թույլտվություններ ունի հատկանիշը:
1. Մուտքի թույլտվություններ.
- ընթերցում
- գրառում
- Կարդալ եւ գրել
2. Նույնականացման թույլտվություն.
- նույնականացում է պահանջվում
- նույնականացում չի պահանջվում
3. Թույլտվության թույլտվություն.
- պահանջվում է թույլտվություն
- թույլտվություն չի պահանջվում
Ատրիբուտի լուծման և բնորոշ հատկությունների հիմնական տարբերությունն այն է, որ առաջինները վերաբերում են սերվերներին, իսկ երկրորդները՝ հաճախորդներին: Սերվերին կարող է թույլատրվել կարդալ բնորոշ արժեքը, սակայն կարող է պահանջվել նույնականացում կամ թույլտվություն: Հետևաբար, երբ հաճախորդը պահանջի հատկանիշի հատկությունները, մենք կստանանք, որ ընթերցումը թույլատրված է: Բայց երբ փորձում ենք կարդալ, սխալ ենք ստանում։ Հետևաբար, մենք կարող ենք ապահով կերպով խոսել սեփականության նկատմամբ թույլտվությունների առաջնահերթության մասին: Հաճախորդի կողմից մենք չենք կարող իմանալ, թե ինչ թույլտվություններ ունի հատկանիշը:
Նկարագրիչ
Վերադառնանք մեր սեղանին։ Բնութագրի արժեքը հայտարարելուց հետո հնարավոր են հետևյալ հատկանիշների հայտարարագրերը.
1. Բնութագրերի նոր հայտարարություն (ծառայությունը կարող է ունենալ բազմաթիվ բնութագրեր)
2. Նոր ծառայության հայտարարագիր (աղյուսակում դրանցից շատերը կարող են լինել)
3. Բռնակ հայտարարելը
Սրտի հաճախության չափման հատկանիշի դեպքում մեր աղյուսակում բնորոշ արժեքի հայտարարագրումը ուղեկցվում է նկարագրիչի հայտարարագրով։ Նկարագրիչը հատկանիշ է, որն ունի հատկանիշի մասին լրացուցիչ տեղեկություններ: Նկարագրիչների մի քանի տեսակներ կան. Դրանց մասին մանրամասն կխոսենք այս հոդվածի երկրորդ մասում։ Առայժմ մենք կանդրադառնանք միայն Հաճախորդի բնութագրերի կազմաձևման նկարագրիչին (CCCD): Այն ունի UUID, որը հավասար է 0x2902-ի: Օգտագործելով այս նկարագրիչը՝ հաճախորդը հնարավորություն ունի միացնել սերվերի վրա նշումը կամ ծանուցումը: Նրանց միջև տարբերությունը փոքր է, բայց դեռ կա: Ծանուցումը չի պահանջում հաճախորդից ստացման հաստատում: Ցուցումը պահանջում է դա, չնայած դա տեղի է ունենում GATT մակարդակում, չհասնելով կիրառման մակարդակին: Ինչու՞ այդպես, հարցնում ես: Ավաղ, ես դա չգիտեմ: Միայն ասեմ, որ սկանդինավյան փորձագետները խորհուրդ են տալիս օգտագործել ծանուցումներ։ Ավելին, փաթեթի ամբողջականության ստուգումը (CRC-ի միջոցով) տեղի է ունենում երկու դեպքում էլ:
Ամփոփում
Հոդվածի վերջում ես կցանկանայի ասել սա. Վերջին աղյուսակը մի փոքր շփոթեցնող է: Այնուամենայնիվ, ես ընտրեցի այն, քանի որ այն տրված է , որի վրա ես ապավինում եմ։ Իմ հոդվածի երկրորդ մասում ես մտադիր եմ ավելի խորանալ BlueTooth 4.0 ճշգրտման մեջ: Այնտեղ մեզ ավելի ճիշտ դիագրամներ և գծագրեր են սպասում։ Երրորդ մասում ես կցանկանայի վերլուծել Wireshark ծրագրի միջոցով ձեռք բերված տեղեկամատյանը գաջեթներից մեկից և տեսնել «կենդանի» ամբողջ տեսությունը, որը մենք ուսումնասիրում ենք:
Ընկերությունների խմբի աշխատակից
Պեչերսկիխ Վլադիմիր
Source: www.habr.com