ચેનલ પર તમામ IPv6 નોડ્સને પિંગ કરો

દરે નવો પ્રવાહ શરૂ થવામાં થોડા દિવસો બાકી છે "નેટવર્ક એન્જિનિયર" OTUS માંથી. આ સંદર્ભમાં, અમે તમારી સાથે વિષય પર ઉપયોગી સામગ્રીનો અનુવાદ શેર કરવા માંગીએ છીએ.

IPv6 પિંગ સમસ્યાઓના મુશ્કેલીનિવારણ માટે ટિપ્સ અને યુક્તિઓ પર બ્લોગ પોસ્ટ્સની શ્રેણી (ICMPv6 ઇકો વિનંતી/ઇકો જવાબ)

મહેરબાની કરીને નોંધ કરો કે હું Linux (ખાસ કરીને Fedora 31) નો ઉપયોગ કરું છું, જો કે અન્ય ઑપરેટિંગ સિસ્ટમો માટે પિંગ કમાન્ડ સિન્ટેક્સ આશા છે કે ખૂબ સમાન હોવું જોઈએ.

ચેનલ પર તમામ IPv6 નોડ્સને પિંગ કરો

પ્રથમ અને સરળ ટીપ એ લિંક પરના તમામ IPv6 નોડ્સને પિંગ કરવાની છે.

IPv6 તમામ પ્રકારના એક-થી-ઘણા સંચાર માટે મલ્ટિકાસ્ટ એડ્રેસનો ઉપયોગ કરે છે. ત્યાં કોઈ બ્રોડકાસ્ટ (અથવા બ્રોડકાસ્ટ) IPv6 સરનામાં નથી. આ IPv6 ને IPv4 થી અલગ પાડે છે, જ્યાં ઘણા પ્રકારના બ્રોડકાસ્ટ એડ્રેસ છે, ઉદાહરણ તરીકે, “મર્યાદિત બ્રોડકાસ્ટ” એડ્રેસ 255.255.255.255 [RFC1122].

જો કે, ત્યાં "ઓલ-નોડ્સ મલ્ટિકાસ્ટ" IPv6 સરનામું છે, તેથી અમે તેનો ઉપયોગ લિંક પરના તમામ IPv6 નોડ્સને પિંગ કરવા માટે કરીશું. (એક "બ્રૉડકાસ્ટ" સરનામું વાસ્તવમાં માત્ર એક ખાસ નામનું મલ્ટિકાસ્ટ સરનામું છે, જે એક મલ્ટિકાસ્ટ જૂથ છે જેમાં તમામ નોડ્સ શામેલ છે. નોંધ કરો કે, ઉદાહરણ તરીકે, લિંક લેયર પર ઇથરનેટ બ્રોડકાસ્ટ એડ્રેસમાં "ગ્રુપ" અથવા મલ્ટિકાસ્ટ એડ્રેસ બીટ ચાલુ છે. ).

ચેનલ માટે ઓલ-નોડ્સ મલ્ટિકાસ્ટ IPv6 સરનામું: ff02::1. ff મલ્ટિકાસ્ટ IPv6 સરનામું સૂચવે છે. આગામી 0 એ અનસેટ બિટ્સ સાથે ધ્વજનો ભાગ છે.

વધુ 2 મલ્ટિકાસ્ટ જૂથના વિસ્તારને વ્યાખ્યાયિત કરે છે. મલ્ટિકાસ્ટ IPv4 એડ્રેસથી વિપરીત, મલ્ટિકાસ્ટ IPv6 એડ્રેસનો અવકાશ હોય છે. અવકાશ મૂલ્ય નેટવર્કનો તે ભાગ સૂચવે છે કે જેના પર મલ્ટિકાસ્ટ પેકેટને ફોરવર્ડ કરવાની મંજૂરી છે. એકવાર પેકેટ નિર્દિષ્ટ કાર્યક્ષેત્રની સીમા પર પહોંચી જાય, પછી પેકેટને છોડવું આવશ્યક છે, પછી ભલે તેનું હોપ કાઉન્ટ ફીલ્ડ બિનશૂન્ય હોય. અલબત્ત, જો હોપની સંખ્યા નિર્દિષ્ટ મલ્ટિકાસ્ટ ગ્રૂપ બાઉન્ડ્રી સુધી પહોંચતા પહેલા શૂન્ય પર પહોંચી જાય, તો તે પણ તરત જ રીસેટ થઈ જાય છે. અહીં IPv6 મલ્ટિકાસ્ટ સ્કોપની સંપૂર્ણ સૂચિ છે.

છેવટે ::1 ઓલ-નોડ્સ મલ્ટિકાસ્ટ જૂથનો ઉલ્લેખ કરે છે.

સરનામા વિશે ff02::1 એ નોંધવું જોઇએ કે તે અસ્પષ્ટ છે. બહુવિધ ઇન્ટરફેસ સાથે IPv6 હોસ્ટ પર, જેમ કે રાઉટર અથવા મલ્ટિહોમ હોસ્ટ, સરનામું ff02::1 ICMPv6 ઇકો વિનંતીઓ કયા ઇન્ટરફેસને મોકલવી અથવા જ્યારે તેઓ આવે ત્યારે ICMPv6 ઇકો જવાબો પ્રાપ્ત કરવાની અપેક્ષા રાખતા હોય ત્યાં તમે સ્પષ્ટ કરી શકો એવું કંઈ નથી. ff02::1 માન્ય છે અને મલ્ટી-ઈન્ટરફેસ નોડ સાથે જોડાયેલ કોઈપણ ઈન્ટરફેસ અને ચેનલો પર વાપરી શકાય છે.

તેથી જ્યારે આપણે બધા IPv6 નોડ્સને લિંક પર પિંગ કરીએ છીએ, ત્યારે આપણે કોઈક રીતે ઉપયોગિતાને પણ જણાવવાની જરૂર છે ping IPv6 માટે, કયા ઇન્ટરફેસનો ઉપયોગ કરવો.

ઇન્ટરફેસ વ્યાખ્યાયિત - આદેશ વાક્ય વિકલ્પ

જેમ આપણે પહેલાથી જ જોયું છે, આપણે જે ઓલ-નોડ્સ મલ્ટિકાસ્ટ એડ્રેસનો ઉપયોગ કરવા માંગીએ છીએ તે છે − ff02::1 - કયા ઇન્ટરફેસને ICMPv6 ઇકો રિક્વેસ્ટ અને ઇકો રિપ્લાય પેકેટ્સ મોકલવા અને પ્રાપ્ત કરવા તે અંગે કોઈ માહિતી આપતું નથી.

તો, આપણે મલ્ટિકાસ્ટ એડ્રેસ સ્પેસ અથવા યુનિકાસ્ટ લિંક-લોકલ એડ્રેસ સ્પેસ માટે ઉપયોગમાં લેવાતા ઈન્ટરફેસને કેવી રીતે સ્પષ્ટ કરીએ?

પ્રથમ અને સૌથી સ્પષ્ટ રીત એ છે કે અમે જે એપ્લિકેશનનો ઉપયોગ કરી રહ્યા છીએ તેના પેરામીટર તરીકે તેને પ્રદાન કરવું.

ઉપયોગિતા માટે ping અમે તેને વિકલ્પ દ્વારા પ્રદાન કરીએ છીએ -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
 
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

આ ઓલ-નોડ્સ મલ્ટિકાસ્ટ પિંગનો ઉપયોગ કરીને, અમને 6 IPv6 નોડ્સ તરફથી પ્રતિસાદ મળ્યો. પ્રતિસાદો ઉપસર્ગથી શરૂ થતાં, Link-Local IPv6 નોડ એડ્રેસ પરથી આવ્યા છે fe80::/10.

પ્રતિ ping ICMPv6 ઇકો વિનંતીઓ જ્યાં સુધી અમે તેમાં વિક્ષેપ ન પાડીએ ત્યાં સુધી અનિશ્ચિત સમય માટે મોકલવાનું ચાલુ રાખતું નથી, અમે સામાન્ય રીતે -c વિકલ્પ દ્વારા મોકલવા માટેના પેકેટોની સંખ્યાનો ઉલ્લેખ કરીએ છીએ. જો કે, આ મલ્ટિકાસ્ટ ICMPv6 ઇકો વિનંતી મોકલતી વખતે પિંગને એક કરતાં વધુ ICMPv6 ઇકો જવાબ સ્વીકારવા અને પ્રદર્શિત કરવાથી પણ અટકાવે છે. તેના બદલે, અમે એ સ્પષ્ટ કરવા માટે -w વિકલ્પનો ઉપયોગ કર્યો છે કે પિંગ 1 સેકન્ડ પછી પૂર્ણ થવી જોઈએ, પછી ભલે ગમે તેટલી ICMPv6 ઇકો વિનંતીઓ અથવા ઇકો જવાબો મોકલવામાં અથવા પ્રાપ્ત થયા હોય.

ધ્યાન રાખવા જેવી બીજી બાબત છે (DUP!) બીજા અને અનુગામી જવાબો પર આઉટપુટ. આ પેકેટોને ડુપ્લિકેટ પ્રતિસાદો તરીકે ઓળખવામાં આવે છે કારણ કે તેમની પાસે વ્યક્તિગત ICMPv6 ઇકો વિનંતીઓ જેવી જ ICMP ક્રમ મૂલ્ય છે જે પ્રથમ સ્થાને મોકલવામાં આવી હતી. તેઓ દેખાય છે કારણ કે ICMPv6 મલ્ટિકાસ્ટ ઇકો વિનંતી બહુવિધ વ્યક્તિગત યુનિકાસ્ટ પ્રતિસાદોમાં પરિણમે છે. ડુપ્લિકેટ્સની સંખ્યા પણ આંકડા સારાંશમાં દર્શાવેલ છે.

ઇન્ટરફેસ વ્યાખ્યાયિત - ઝોન ID

ઉપયોગ માટે ઈન્ટરફેસને ઉજાગર કરવાની બીજી રીત IPv6 એડ્રેસ પેરામીટરના ભાગરૂપે છે.

અમે પિંગ આઉટપુટમાં આનું ઉદાહરણ જોઈ શકીએ છીએ, જ્યાં પ્રતિસાદ આપતા IPv6 હોસ્ટના સરનામાંઓ પણ પ્રત્યય ધરાવે છે. %enp3s2, ઉદાહરણ તરીકે:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

ઈન્ટરફેસનો ઉલ્લેખ કરવાની આ પદ્ધતિ ઔપચારિક રીતે [RFC4007], "IPv6 ડિફાઈન્ડ એડ્રેસ આર્કિટેક્ચર." જો કે તેઓને સામાન્ય રીતે ઓપરેટિંગ સિસ્ટમ ઈન્ટરફેસ કહેવામાં આવે છે, તેઓ વાસ્તવમાં કંઈક વધુ સામાન્ય વ્યાખ્યાયિત કરે છે - "ઝોન" અથવા "સ્કોપ."

વધુ સામાન્ય ઝોન અથવા સ્કોપ ઝોન રાખવાનું કારણ એ છે કે, [RFC4007] માં જણાવ્યા મુજબ, IPv6 નોડમાં એક જ ચેનલ સાથે જોડાયેલા ઘણા અલગ IPv6 ઇન્ટરફેસ હોઈ શકે છે. આ ઇન્ટરફેસો એ જ ઝોનના સભ્યો છે.

ઑપરેટિંગ સિસ્ટમ હેઠળ એક ઝોનની અંદર બહુવિધ ઇન્ટરફેસને જૂથબદ્ધ કરવાનું શક્ય હોવું જોઈએ; હાલમાં મને ખબર નથી કે આ Linux હેઠળ શક્ય છે કે કેવી રીતે કરવું.

પ્રત્યયનો ઉપયોગ કરીને %<zone_id>, આપણે આદેશ વાક્ય વિકલ્પને દૂર કરી શકીએ છીએ -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

લિંક-સ્થાનિક સરનામાં પ્રતિસાદો

આ ઓલ-નોડ્સ મલ્ટીકાસ્ટ પિંગમાંથી અમને કુલ 6 અનન્ય પ્રતિસાદ મળ્યા.

આ પ્રતિભાવો unicast Link-Local IPv6 હોસ્ટ એડ્રેસ પરથી આવ્યા છે. ઉદાહરણ તરીકે, અહીં પ્રથમ જવાબ છે:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

યુનિકાસ્ટ લિંક-લોકલ IPv6 સરનામાં બધા IPv6-સક્ષમ ઇન્ટરફેસ [RFC4291], “IP સંસ્કરણ 6 એડ્રેસિંગ આર્કિટેક્ચર” પર જરૂરી છે. આનું કારણ એ છે કે IPv6 નોડમાં હંમેશા આપમેળે યુનિકાસ્ટ IPv6 સરનામું હોય છે, જેનો ઉપયોગ તે તેની સીધી જોડાયેલ લિંક્સ પર અન્ય નોડ્સ સાથે વાતચીત કરવા માટે કરી શકે છે. આમાં લિંક-લોકલ હોસ્ટ એડ્રેસ દ્વારા અન્ય હોસ્ટ પર એપ્લિકેશન્સ સાથે વાતચીત કરવાનો સમાવેશ થાય છે.

આ IPv6 નેબર ડિસ્કવરી અને OSPFv3 જેવા પ્રોટોકોલની ડિઝાઇન અને અમલીકરણને સરળ બનાવે છે. તે યજમાનો પરના અંતિમ-વપરાશકર્તા એપ્લિકેશનોને ચેનલ પર કોઈપણ અન્ય સહાયક IPv6 ઈન્ફ્રાસ્ટ્રક્ચરની જરૂર વગર ચેનલ પર વાતચીત કરવાની મંજૂરી આપે છે. કનેક્ટેડ IPv6 હોસ્ટ્સ વચ્ચેના સીધા સંચાર માટે કનેક્શન પર IPv6 રાઉટર અથવા DHCPv6 સર્વરની જરૂર નથી.

લિંક-સ્થાનિક સરનામાં 10-બીટ ઉપસર્ગથી શરૂ થાય છે fe80, ત્યારબાદ 54 શૂન્ય બિટ્સ અને પછી 64-બીટ ઇન્ટરફેસ આઇડેન્ટિફાયર (IID). ઉપરના પ્રથમ જવાબમાં 2392:6213:a15b:66ff 64-બીટ IID છે.

લૂપ્ડ મલ્ટિકાસ્ટ

મૂળભૂત રીતે, મલ્ટીકાસ્ટ પેકેટો તેમને મોકલેલ નોડ પર આંતરિક રીતે પરત કરવામાં આવે છે. આ IPv6 અને IPv4 એડ્રેસિંગ બંને માટે થાય છે.

આ ડિફૉલ્ટ વર્તણૂકનું કારણ એ છે કે જ્યારે મલ્ટિકાસ્ટ પેકેટો મોકલવામાં આવે છે, ત્યારે ત્યાં એક સાંભળવાની સ્થાનિક મલ્ટિકાસ્ટ એપ્લિકેશન પણ હોઈ શકે છે જે મોકલનાર હોસ્ટ પર જ ચાલી રહી છે, તેમજ નેટવર્ક પર ક્યાંક. આ સ્થાનિક એપ્લિકેશનને મલ્ટીકાસ્ટ પેકેટો પણ પ્રાપ્ત કરવા આવશ્યક છે.

અમે અમારા પિંગ આઉટપુટમાં આ મલ્ટિકાસ્ટ લોકલ લૂપ જોઈ શકીએ છીએ:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...

પ્રથમ અને સૌથી ઝડપી પ્રતિસાદ (0,106 ms ની સરખામણીમાં 0,453 ms) ઈન્ટરફેસ પર જ રૂપરેખાંકિત લિંક-લોકલ એડ્રેસમાંથી આવે છે. enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

ઉપયોગિતા ping પરિમાણનો ઉપયોગ કરીને સ્થાનિક મલ્ટિકાસ્ટ પ્રતિસાદને દબાવવાનો માર્ગ પૂરો પાડે છે -L. જો આપણે આ ફ્લેગ સાથે ઓલ-નોડ્સ મલ્ટિકાસ્ટ પિંગ મોકલીએ, તો જવાબો રિમોટ નોડ્સ સુધી મર્યાદિત છે. અમને મોકલવાના ઈન્ટરફેસના લિંક-લોકલ એડ્રેસ પરથી પ્રતિસાદ મળતો નથી.

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
 
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...

પિંગ લિંક-સ્થાનિક સરનામાં

જેમ તમે અનુમાન લગાવી શકો છો, યુનિકાસ્ટ લિંક-લોકલ એડ્રેસ પણ તેમના સુધી પહોંચવા માટે કયા ઇન્ટરફેસનો ઉપયોગ કરવો તે સૂચવવા માટે પૂરતી માહિતી પ્રદાન કરતા નથી. ઓલ-નોડ્સ મલ્ટિકાસ્ટ પિંગની જેમ, અમારે કમાન્ડ લાઇન પેરામીટર તરીકે ઇન્ટરફેસનો ઉલ્લેખ કરવાની પણ જરૂર છે. ping અથવા લિંક-લોકલ એડ્રેસને પિંગ કરતી વખતે એડ્રેસ સાથે ઝોન ID.

આ વખતે આપણે ઉપયોગ કરી શકીએ છીએ -cમોકલેલા અને પ્રાપ્ત થયેલા પેકેટો અને પ્રતિસાદોની સંખ્યા મર્યાદિત કરવા ping, કારણ કે અમે યુનિકાસ્ટ પિંગ કરી રહ્યા છીએ.

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
 
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

અન્ય IPv6 સરનામાંને પિંગ કરીએ?

આ લેખમાં, અમે જોયું કે ઓલ-નોડ્સ મલ્ટિકાસ્ટ IPv6 એડ્રેસનો ઉપયોગ કરીને ચેનલ પર તમામ IPv6 નોડ્સને કેવી રીતે પિંગ કરવું. ff02::1. અમે એ પણ જોયું કે ઓલ-નોડ્સ મલ્ટિકાસ્ટ IPv6 સરનામાં સાથે કયા ઇન્ટરફેસનો ઉપયોગ કરવો તે કેવી રીતે સ્પષ્ટ કરવું, કારણ કે સરનામું પોતે આ માહિતી પ્રદાન કરી શકતું નથી. અમે ક્યાં તો આદેશ વાક્ય વિકલ્પનો ઉપયોગ કર્યો ping, અથવા પ્રત્યયનો ઉપયોગ કરીને ઇન્ટરફેસનો ઉલ્લેખ કરો %<zone_id>.

પછી અમે યુનિકાસ્ટ લિંક-લોકલ એડ્રેસ વિશે શીખ્યા, જે ઓલ-નોડ્સ મલ્ટીકાસ્ટ ICMPv6 ઇકો વિનંતીઓને પ્રતિસાદ આપવા માટે વપરાતા સરનામાં છે.

અમે એ પણ જોયું કે કેવી રીતે મલ્ટીકાસ્ટ પેકેટો ડિફોલ્ટ રૂપે મોકલવાના નોડ પર પાછા આવે છે અને ઉપયોગિતા માટે આને કેવી રીતે અક્ષમ કરવું ping.

છેલ્લે, અમે પ્રત્યયનો ઉપયોગ કરીને એક જ લિંક-લોકલ એડ્રેસ પિંગ કર્યું %<zone_id>, કારણ કે લિંક-સ્થાનિક સરનામાંઓ પોતે પણ આઉટગોઇંગ ઇન્ટરફેસ વિશે માહિતી પ્રદાન કરતા નથી.

તો અન્ય તમામ નોડ્સને પિંગ કરવા અને તેમના વૈશ્વિક યુનિકાસ્ટ સરનામાં (GUAs) (એટલે ​​કે, ઇન્ટરનેટ પર તેમના જાહેર સરનામાં) અથવા તેમના અનન્ય સ્થાનિક યુનિકાસ્ટ સરનામાં (ULAs) વિશે શું? અમે આને આગામી બ્લોગ પોસ્ટમાં જોઈશું.

બસ.

તમે અહીં અમારા કોર્સ વિશે વધુ જાણી શકો છો ઓપન ડે નોટ્સ.

સોર્સ: www.habr.com