C, soket ve client side üzerine düşünceler

[Sypro]

şimdi yapıp yapıp sahaya saldığımız modüller düşünün, program kısmı komple c ile yazılmış olan. velev ki bunlar internete bağlanmayı başardı, bunların belirli bir ip'ye bağlanıp ne olduğu çok da mühim olmayan bir port'a bir şeyler göndermesini (hatta mümkünse iki yönlü bir iletişim) sağlatmak için bir şeyler yapma düşüncem var.
çok acelesi olan bir şey değil, o yüzden adam gibi araştıracak vaktim var. sorun ne olarak arayacağımı bilmiyor oluşum.
bu arada ben karşı tarafın ip'sini ya da port forwarding bilmemne meselelerini bilmiyor olucam. geri bir şey göndermek istediğimde alacak kişinin istediğim kişi olduğundan nasıl emin olacağımı çözmeye çalışıyorum.
komple c. su katılmamış. gcc ile derleyip sıcak servis yapılan türden.
saygılar sevgiler.

[Kharon]

c socket programming?

[SpiderS_DangeR]

Komple C yerine, C# falan yazsan cok guzel teknolojiler var hic portdu bytedi paketdi ugrasmadan direk classlarin instancelarini yollayabilecegin?

[Sypro]

KHaRoN said:

c socket programming?

teşekkür ederim, hiç düşünememişim.

maalesef c# seçeneklerin dışında. belki cpp, o da uğraşacak halim olursa. öncelik c o yüzden.

[Lancelion]

http://www.beej.us/guide/bgnet/

dünyadaki en iyi socket programming kaynağı heralde bu

[Kharon]

sarcasm guzel de o sekilde aradiginda cikicak ilk 3 sonuctan birisi lancelion un gosterdigi gibi beej e varicakti. Obvious, ama basarili.

[Fly]

raw soketler uzerine insaa edecegin custom bir protokol o zaman ?

[Sypro]

beej örneklerine başka bir şey için bakmıştım, hatırladığım kadarıyla karşılıklı bir iletişim methodu içermiyordu. ya da ben o an sadece belli bir porta belli bir mesaj gönderme çabası içinde olduğum için çok da alıcı gözüyle bakmadım. emin değilim.

amacım soket programlama ile genel ilgili araştırmadan ziyade daha spesifik bir şey üzerine araştırmak olduğu için tepkiydi sadece. sarkastik olsun diye yazmadım yani.

hazır bir şeylerden ziyade evet, daha özelleştirilmiş bir şeylere ihtiyaç olacak gibi.

bu arada tüm olan biten ARM üzerinde olduğu için mecburen c. öyle hayvan gibi konfigürasyon falan da düşünmeyin mümkünse. toplasan zaten 256kb yer var. iki soket açayım derken memory kalmıyor. sanırım böyle dersem "c socket programming" den daha fazlasına ihtiyacım olduğu anlaşılır.

[Fly]

uzerinde calistigi os, uygulamalarin ne kadar delayli sekilde iletistigi, transfer hizindan beklentin vs ?

[Sypro]

os? os denebilecek bir yapı yok ortada. güzel bir PCB, üzerine yerleşmiş güzel güzel parçalar falan var. bi de işte ARM işlemci var. toplam 256kb diyorum. tcp/ip protokolünün tamamını çalıştırmaya yetecek mi o bile kesin değil, ıvır zıvır ne varsa kısmaya çabalamak gerekecek sonradan.
çok büyük bir performans beklentisi yok yani. kararlı çalışsın öncelikli olarak.

[Fly]

networking librarysi (en azindan ip pakedi al ver yaptiran) vardir ama ustune koyacaginiz ?

yani neyse, api kisminda cok ekstrem bisey yok zaten :
suraya paket yollamaya calis, sunu dinle disinda basta ve sondaki angaryalar var ip/udp paketleriyle calisacaksan

cihazda degilse de bilgisayarda pratik yapmak istersen raw ip soketler
veya root permission ivir zivirina bulasmayayim dersen udp soketler ile pratik yap (zira ip'nin ustune portlara dagilim ve tek bir udp pekdini olusturan ip paketlerinin birlesip uygulamaya gelisi disinda bisey katmiyor pek, paket al gonder yaparken uygulayacagin muamele neredeyse direk ayni)

soketi gec protokol nasil calismali onu bilmiyorum asil dersen uygulamada ne yapacagina bagli, soyle boyle olmali demek yanlis olur

ayni odada iletisen ufak robotlar icin lockstep kafasinda calisan ve sifira yakin overheadi olan bisey de olabilir
p2p bir network icin onlarca buffer tutan, tcp+torrent karisimi biseyin sifirdan implementasyonu da

ne istedigine gore varolan seylerin rfc'lerini aratarak, ietf'nin linklerden bakarak nasil calistiklarina bak

tcpnin portsuz calisan bir implementasyonuna giriserek baslayabilirsin mesela

ama reliable iletisim olsun dersen window vb mekanizmalardan kacman cok zor, genel amacli, tcpvari garantiler saglayan protokoller icinde kullanmayanina pek rastlamadim

window icin ayrilan default memory miktarindan kisip dusuk latencyde isini gorecek seviyede calisan bir seyler elde edebilirdin tcpyle port mevzusu olmasa

[Sypro]

tişikkirlir öncelikle.

amaç aslında başlangıçta udp kullanarak (tcp/ip hem yer hem de uğraş gerektiriyor) bir iletişim kurma çabası zaten.
soketi c içerisinde defalarca farklı şeylerde kullandım, php içerisinden de aynı şekilde defalarca kullandım. derdim soket ile ya da nasıl kullanılacakla falan değil yani. anlatmaya çalıştım ama anlaşılmadı, biraz daha açayım en iyisi, belki başkaları da benzer bir şey arar sonradan.

şimdi dediğim gibi arm işlemcili bir kart var ortada. ne yaptığı çok mühim değil. içinde çalışan bir program var. bir (veya çok gerekli olması durumunda iki) adet de portu dinleyen bir şey var üzerinde. asıl mesele bu kart 'herhangi' bir noktadayken internete bağlandığı vakit benim sabit ip'min belli bir port'una 'müdür, ben burdayım, ne yapayım' diye sorması. bunu yapmak basit. mesele ben ona geri dönüşte 'tamam, seni gördüm, şimdi şunu yap' diye cevap verdiğimde bu cevabın gideceği yer. çünkü alet bana router arkasından da gelebilir, elli tane yerden geçip de gelebilir, dümdüz bulduğu bağlantıdan da gelebilir. bunu öngörmenin imkanı yok şu an. ben ona 'şunu yap' dediğimde normal şartlarda cevabın döneceği yer son çıktığı ip olacak muhtemelen. ama içerdeki yapıyı, varsa port forwarding meselelerini falan bilme imkanım olmadığı için cevap o vatandaşa gidecek mi gitmeyecek mi bunu kestiremiyorum. neticede benim elimde source ve destination var ama bu destination gideceği yere mi ait yoksa en dıştaki ip'ye mi ait bunun bilgisi yok.
şimdiye kadarki işlemlerde hep kendi açtığım portlar üzerinden veri akışını gerçekleştirdim ve hepsi ulaşacağımdan emin olduğum yerlerdeydi. burada öyle değil işler. merak ettiğim kısım buydu işin özünde, olay niyeyse soket programlama 101 olayına döndü bir anda.
dışarıya 195.194.187.25 ile çıkan bir alet içerde 192.168.3.50 ip'sini almış olabilir. ben 195'e dönersem bunun içeride 50'ye gidebilmesini herhangi bir düzenleme yapmadan nasıl sağlarım yani aradığım. soket açık kaldığı sürece iletişim doğru şekilde gerçekleşecek mi mesela?
falan filan. kafamda deli sorular yani. kaldı ki dediğim gibi, acelesi olmayan, ama olursa çok kral olacak bir mesele bu.
araştırmaya devam.

[BioHazarD]

bilmiyorum dediginin olurlugunu ama workaround olarak kenarda dursun soyle:

alet (A) sabit ipli programa (P) baglanir.
P, A icin responseunu bir dosyaya yazar (A'nin son IP'si.txt mesela veya baska bir identifier).
A, kendi IP'sini (veya baska bir identifierini) alarak, P'nin bulundugu yerden o dosyayi okur.

[Zikko]

router üzerinden gelen ip NAT var ise tablo'da tutuluyor ve o nat tablosuyla eşleştirme yapıp o paketin nerden geldiğini port ile birlikte anlayabiliyor olman gerekiyor.

nat tablo işlemlerini incelemeni tavsiye edebilirim.

[Gladmir]

Socket in dogasi geregi, bir kez acilirsa, o route uzerinde ki network device lar socket up oldugu surece transport u korur. Tabii ki acik olan socket den gonderdigin paket socketin diger end point ine ulasir.

Trojan pattern; Device i trusted/protected domain e sokup icerden disariya dogru bilinen portlardan socket acarsin. Arada firewall var ise, outgoing rule lara carpabilirsin, device i nereye koyacagina bagli sonucta.

Kharon C Socket Programming demis, ben biraz degistireyim onu.

Embedded C native socket designs
M2M design patterns (Machine to Machine)