Asp.Net de Ip yi almak

[zgrw]

Request.ServerVariables("REMOTE_ADDR")

'System.Web.HttpRequest.ServerVariables' denotes a 'property' where a 'method' was expected

yukardaki fonksiyonu kullanınca şu hatayı veriyor :)

yapmaya çalıştığım olay şudur , bunu alıp önce bir string e daha sonrada database e yazdıracağım :)[signature][hline]Her sabah yolunu gözlerim ,
Buğdayların arasındaki yeşil okyanusları görebilmek ,
Kır çiçeklerinin kokusunu duyabilmek ,
Beni sevdiğini hayal edebilmek için...
Geyyik
[Bu imza zgrw tarafından 18 January 2004 17:38 tarihinde değiştirilmiştir]

[Ceday]

property dedigine göre o hashtable falan.
(..) yerine [..] kullan

[zgrw]

harika bi insansın ya :D şu errorlerin ne demek istediklerinin ta olarak çözdüğümde bu işi bitirecem demekki :D ama bunu unutmam bi daha :D[signature][hline]Her sabah yolunu gözlerim ,
Buğdayların arasındaki yeşil okyanusları görebilmek ,
Kır çiçeklerinin kokusunu duyabilmek ,
Beni sevdiğini hayal edebilmek için...
Geyyik
[Bu imza zgrw tarafından 18 January 2004 17:38 tarihinde değiştirilmiştir]

[Mum_Chamber]

string ip = Request.ServerVariables("REMOTE_ADDR");

atama yapmadıysan o hatayı alıyor olabilirsin.[signature][hline]en ince yerim bileğim..!?!
BandRoLL

[Rahan]

konuyla az alakalı olarak, ip yi 32 bit tamsayı olarak da tutabilirsin.(hatta tutmalısın) çeviri için fonksiyonlar vardır herhal.[signature][hline]pppppt.. kediler çorba içmezki!

[MrMedia]

gerçek IP adresi için HTTP_X_FORWARDED_FOR uda kullanabilirsin.[signature][hline]I Love Liv Tyler | IP Adresim Ne ? | BedaXa |
Matrix Code System

[Ceday]

said:

Rahan, 10 Eylül 2005 10:11 tarihinde demiş ki:
konuyla az alakalı olarak, ip yi 32 bit tamsayı olarak da tutabilirsin.(hatta tutmalısın) çeviri için fonksiyonlar vardır herhal.

genelde cogu fonksiyon string olarak alıo ip yi.

hem zaten int halinde nası tutcan ki? "." lerin nerde oldugunu anlayamazsın?

[zgrw]

said:

Ceday, 10 Eylül 2005 00:23 tarihinde demiş ki:
property dedigine göre o hashtable falan.
(..) yerine [..] kullan

sorun buymuş :)[signature][hline]Her sabah yolunu gözlerim ,
Buğdayların arasındaki yeşil okyanusları görebilmek ,
Kır çiçeklerinin kokusunu duyabilmek ,
Beni sevdiğini hayal edebilmek için...
Geyyik
[Bu imza zgrw tarafından 18 January 2004 17:38 tarihinde değiştirilmiştir]

[zgrw]

bu arada işimi gördü zaten :) banada string olarak lazım dı :) string ve array lerde çalışmak daha çok hoşuma gidiyor e daha kolay geliyor :)[signature][hline]Her sabah yolunu gözlerim ,
Buğdayların arasındaki yeşil okyanusları görebilmek ,
Kır çiçeklerinin kokusunu duyabilmek ,
Beni sevdiğini hayal edebilmek için...
Geyyik
[Bu imza zgrw tarafından 18 January 2004 17:38 tarihinde değiştirilmiştir]

[Rahan]

said:

Ceday, 10 Eylül 2005 21:11 tarihinde demiş ki:
genelde cogu fonksiyon string olarak alıo ip yi.

hem zaten int halinde nası tutcan ki? "." lerin nerde oldugunu anlayamazsın?

veritabanında kapladığı alan az olur. arandığında bulunması kolay olur.

noktaları aradan çekip sayı yapmayacaksın tabi ki kısaca sölemek gerekirse 256lık sayı tabanında 4 basamaklı bir sayı olarak görebilirsin ip yi.[signature][hline]pppppt.. kediler çorba içmezki!

[Ceday]

bence yersiz olurdu

yani onun db de tutcagı yeri dert etme :)

[Mum_Chamber]

said:

zgrw, 10 Eylül 2005 21:18 tarihinde demiş ki:

said:

Ceday, 10 Eylül 2005 00:23 tarihinde demiş ki:
property dedigine göre o hashtable falan.
(..) yerine [..] kullan

sorun buymuş :)

o zaman c# kullanıyorsun? (vb.net kullansan "()" de kabul eder miydi diye şeettirdim)

ayrıca ben de rahandan yanayım. mükemmeliyet teferruatlarda gizlidir.[signature][hline]en ince yerim bileğim..!?!
BandRoLL

[Ceday]

o tür bi design bana kalırsa mükemmel deil de baya kötü olurdu :)

kazandıgın hiçbir sey yok ama kaybedebilecegin cok sey var, ne adam gibi debug edebilirsin ne bişi. elindeki datanın okunabilirligi kalmıyor. o zaman elinizdeki her türlü veriyi sıkıştırdıktan sonra db ye atın yerden kazanıcam die, ben sonra görürüm sizin halinizi :)

adamın ip si die abuk subuk charlar girmenin alemi yok ki db ye. kaldı ki ordan kazanacam die db yi unicode yapman gerekecek. gene abuk subuk chinese karakterlerle felan işin yoksa bence o da gereksiz. db yi unicode yaptın mı zaten kazandıgının en az 1000 mislini kaybedersin..

bir de db boyutu artık hiçbir projede dert edilmiyor. proje kücükse zaten sorun yok. proje büyükse HİÇ dert edilmiyor. Foreign key bile kullanılmıyor büyük projelerde, db designlarını siz düşünün artık. 5000+ tablolu projeler biliyorum sırf sorun olmasın die kullanılmıyor, kullansalar zaten işin içinden cıkamazlar. db design ederken de yerden kar ediyim die kimsenin bi derdi olmuo zaten o tür projelerde. birşey simdi lazım olmasa bile sırf belki ilerde lazım olur die db ye eklenebiliyor.

[Rahan]

ne abuk subuk charı, ne sıkıştırması yafu.. ip dediğin 256*256*256*256 farklı değer alan bi sayı, o da (2^8)^4 demek o da 2 ^32 o da bizim bildiğimiz C deki long veya dword denen veri tipi işte.
nesi sıkıştırma ki bunun?

dbms e ip verip arattırdığında karşılaştırma yapmayacak mı? 15 er bytelık 2 string i mi karşılaştırmak hızlı, 2 tane long değeri mi?
tahminen stringi karşılaştırması bi 4-5 kat fark eder.

büyük proje küçük proje olayına girmenin anlamı yok, benim söylediğim gayet basit bir şekilde; ip adresini veritabanında saklamanın stringden daha hızlı, daha az yer kaplayan yolu.

bi de ilginçtir, derlenmesi saatler süren projelerde falan da çalıştım ama hiç böyle müsriflik yaptığımızı hatırlamıyorum.[signature][hline]pppppt.. kediler çorba içmezki!

[Ceday]

simdi sen onu senin dedigin gibi 32 bitlik bir hale getirince kendi elini kolunu baglıosun. db de gördügün sayıların hangi ip ye denk geldigini direk göremiosun..hadi bunları gectim de, esas sorun istedigini adam gibi yapamayabilirsin.

sen illa ki birebir ip karşılastırcaksın die bişi yok ki.
yerel agdaki görmek istiyorum desen veya ip sinin başı bilmem şu olanları görüyüm desen db onları birebir karşılaştıramaz. senin bunları yapan ek fonksiyonlar yazman gerekecek hep.
durduk yere başına iş açıosun kısaca.

bu basit bi ip örnegi. hersey için yerden kazancam die bu tür şeyler türetmeye kalkarsanız walla o proje batar :)

ha ben burda cok ufak projelerden bahsetmiyorum. bir iki kişilik projeyse belki idare edebilirsin ama 6-7 kişilik bir projeyse (ki 100 lerce kişinin çalıştıgı projeler dahi mevcut) bu gibi şeyler başınıza ummayacagınız dertler açar.

[Bu mesaj Ceday tarafından 11 Eylül 2005 12:38 tarihinde değiştirilmiştir]

[Rahan]

said:

Ceday, 11 Eylül 2005 12:37 tarihinde demiş ki:
ip sinin başı bilmem şu olanları görüyüm desen db onları birebir karşılaştıramaz.

nası karşılaştıramaz? bal gibi karşılaştırı hem de olabilecek en hızlı şekilde. zaten ipyi long olarak saklamak istiyorsam, ip2long ve long2ip diye iki fonksiyon yazmış olurum, diyelim 80 le başlayan ipleri istiyorsun, gayet basit bi şekilde ip2long("80.0.0.0") ile ip2long("81.0.0.0") arasındaki değerlere baktırtırım veritabanından.

son değerleri x olanaları bulmak için sayıyı 2^24 e bölerim kalanını x le karşılaştırtırım veya daha temizi, 0x000000FF le AND (edik; pardon yaf or değil anddd andd) yapar öyle karşılaştırtırım. aradaki değerler için de yine benzeri mask + shift yapar öyle karşılaştırırım.

başıma iş açtığım doğru ama hızlı program böyle böyle çıkar işte. ha benim zamanım yok ucuzundan bişi hazırlıyorum diyosan zaten herşey mübah nasıl yaparsan. ama bu yönteme tezek atmaya gerek yok ki..[signature][hline]pppppt.. kediler çorba içmezki!

[Bu mesaj Rahan tarafından 11 Eylül 2005 13:05 tarihinde değiştirilmiştir]

[Ceday]

ne tür bi hız katcaksın ki rahan bu şekilde programa? optimize edilmeye degecek birşey degil ki bu.

yer olarak da dedigim gibi bugün db'de o kadar şeyin hesabı yapılmıyor bile..

hesabı yapılan tek şey zaman..ama programın degil iş gücünde harcanan zaman. senin bilmem kac nano sn hızlı olcak die yazacagın koda ve tasarlayacagın veritabanına baskası baktıgı zaman birşey anlamayıp fazladan harcayagı vakit önemli asıl.

yani bu senin nası bi projede çalıştıgına göre de değişir önceden de dedigim gibi. sadece senin yaptıgın bir projesyse eyw ama cok kişilik bir projede bu tür değişiklikler fazlasıyla sakıncalı. yine de gercekten ugrasmaya degcek birşey kesinlikle diil derim ben.

[Mum_Chamber]

ceday zaten ip kontrolü için veritabanına hususi bağlanan ya da 5000 tablosu olup da fk kullanmayan bir yazılım ekibiyle çalışıyorsan ortada bir fil kadar ufak bir sorun yok mu?

hem benim demek istediğim de buydu, google'ı daha iyi bir yazılım dili kullanmak değil, iş gücünden verilen bu taviz yarattı. insanların "boşuna iş gücünden kayıp" diyerek kodlamadıkları, yapımı gayet açık ve ortada olan sistemi kodladıkları için (sanırım) 2 sene üst üste en başarılı firma ödülünü aldılar.

yoksa herkesten programcı olur.. herkes veritabanına birşeyler yazıp onları okur. önemli olan ilk baktığında o int değerleri görmek, bu hesaplamaları yapmaktır.[signature][hline]en ince yerim bileğim..!?!
BandRoLL

[Rahan]

2 tane çeviri fonksyonunu (ip2long,long2ip dediklerim) kullanmayı beceremeyen adam da çok kişilik projeye falan girmesin artık ya..

ha anlaması dersen iki fonksyonda c de 10 satır tutmaz. 10 dakkasını veriversin.[signature][hline]pppppt.. kediler çorba içmezki!

[Ceday]

iki şeyi karıştırmamak lazım. ewt google'ı google yapan performansıdır ama performans aranan oldukca az şey var suanki cogu yazılımın şirketinin geliştirdigi projeler arasında..
bugün şirketlerin geliştirdigi cogu commercial productta hızdan daha önemli olan stable olması ve sorunsuz çalışmasıdır.

ewt hız da önemlidir ama burda tartıştıgımız sey benim kanaatimce performansı etkilemiyor. (neglectiable)
performansı etkileyecek şeyler daha büyük çapta seylerdir.
sonucta amaç önemli, google amac hız, hız için her türlü şey de yapılıyor. veya bi oyun yazıosan gene aynı sekilde performans için kasabilirsin..

burdaki olay ise db de daha az yer tutmak, bunun performansla alakası yok, kurtarılan yer önemli bir yer olsa eyw lafım yok da bence hakikaten önemsiz birşey.

o yüzden google burdaki olayı karşılaştırmak pek mantıklı degil.

ha bir de mum, 5000 tablolu bir db'de inan bana fk kullanmak istemezsin. en azından db düzeyinde kesinlikle kullanılmıyor. db için kullanılan ara katmanlarda yapay FK lar yaratılıyor cok önemli şeyler için. dogrusu da bu zaten.

yalnız hele ki burda konustugumuz türden değişiklikleri büyük bir projede yaparsan tam anlamıyla "gg" :)

baya deneyimli bi abi diyebilecegim bi kişinin tecrübelerinden uzun süre yararlandım. adam tr nin en büyük yazılım firmalarının birinde head architect. gelip bize bikaç saat yazılım mimarileri hakkında konusup bişiler anlatmıstı. onca yıllık deneyim yani, benden size tavsiye :)

[Rahan]

said:

Ceday, 11 Eylül 2005 14:34 tarihinde demiş ki:
ewt hız da önemlidir ama burda tartıştıgımız sey benim kanaatimce performansı etkilemiyor. (neglectiable)

eğer veritabanına x'in ip adresi nedir gibi bi sorgu yaparsan performansda kayıp olmaz, ama tam tersini yapmaya çalıştığında yani ip adresini verip x i almak istediğinde bu sefer 15 bytelık bi stringi başka 15 bytelık stringle karşılaştırmak zorunda kalırsın ki, bu da iki longu karşılaştırmaya nazaran performans kaybı yaratır.

nese sen tümden ingilizce konuşmaya başlamadan her yiğidin yoğurt yiğişi farklıdır deyip bırakalım tartışmayı..[signature][hline]pppppt.. kediler çorba içmezki!

[Mum_Chamber]

nası performansla alakası yok? sonuçta sonu .73le biten ipleri hangi sistem daha hızlı bulur? ya da veritabanında nchar fetch mi daha hızlıdır long fetch mi?

ayrıca bir veritabanı uzmanı olarak, oracle'ın yapımcısı da gelse öyle bir veritabanında çalıştıramaz beni :D insan katil olur be..

şaka bir yana bunu diyen kişi clustering(kümeleme) konusunda bilgili miydi? tamam çok iyi programcıdır onu saygım sonduz da, en basit moc'de bile "kesinlikle kümeleme yapılmalı" derken bu duyduğum çok garip geldi. birisi "a'dan sonra c gelir" demiş gibi.. sonuçta sorgu hızı kümeleme ve dolayısıyla indeksleme daha da dolayısıyla fk ile çoook ilişkilidir de..

Not: rahanın yazısını tam yollarken gördüm. evet aslında uzatmaya da gerek yok :D[signature][hline]en ince yerim bileğim..!?!
BandRoLL

[Ceday]

walla bence yazacagınız programdan performans almak istiosanız daha baska yollar üzerinde calısmanız lazım.

cünkü bu tür bi design gerek database olarak gerekse programın işleyişi açısından iyi degil.


@Mum: bunu söyleyen kişinin Java konusunda tr de bi eşi daha olmadıgına eminim. adam 4-5 yıl önce POM (Persistant Object Manager) yazmıs, şuanki Hibernate'in (100K kullanıcısı vardır sanırım) dahi desteklemedigi birtakım featureları mevcut. ki bunu taa ne zaman yazmıs. Bunun yanında DB Cache yazmıs. En önemlisi Rich Thin Client Application Framework yazmıs. (nedir bu die kısaca anlatırsak mesela: bi web browser yaptıgı işi rich clientlarda yapıo. client olarak standart bi engine çalışıyor, server clienta xml gönderiyor, o anda gelen xml'e göre dinamik program oluşturuluyor. yani client dedigin IE gibi bi engin, gelen xml kodunu parse edip dinamik program olustuyor.) bunun için hatta development studio dahi yazmıs. sonucta gönderilcek xml i elle yazmıosunuz, siz yine görsel design yapıosunuz o xml i auto generate edio. her türlü event destegi vs de mevcut.)

Adam bastan sona Application Development Framework yazmıs birisi. Şuan halen free veya commercial olarak yukarda anlattıgım frameworkun piyasada eşlenegi yok. Birtakım bazı seyler var ama bununkinin yanına yaklaşamıolar.

Kısaca adamın bu konuda bilgisini sınamamanızı tavsiye ederim :)

[Ceday]

ya mesela şöle bi örnek veriyim:

40+ kişilik modüler bi proje olsun. (modülerden kasıt herkesin yazdıgı kısımlar birbirinden bagımsız deil, birbirlerinin yazdıgı fonksiyonları cagırıyorlar)

şimdi sizin yazdıgın bi fonksiyonun alması gereken parametreler string, int, date vs türü seyler olsun. eger siz kalkıp fonksiyonun prototype ını bu sekilde tasarlarsanız:
ex) public hede (String, int, date, ..)

simdi bu kötü bir tasarım oluyor. cünkü development aşamasında binbir türlü bela demek. hmzz simdi siz nesi bela ki diebilirsiniz, hatta diyeceksinizdir de..

dielim benim yazdıgım fonksiyon 15-20 kişi tarafından kullanılıyor. ben bu fonksiyona gereksinimden dolayı yarın öbür gün bi parametre daha ekleyip projeyi "commit" ettigim anda o projede çalışan 40 kişi projeden hata almaya baslıyacaklar. Projeyi derleyemediklerinden yaptıkları işi bırakıp senin yaptıgın değişikliklikten dolayı cıkan hatayı düzeltmeleri lazım önce. 15-20 kişiden birisi dahi düzeltmese proje hata verir. Burdaki iş gücü ve zaman kaybının haddi hesabı yok. Adamın o anda konsatre olup yapmaya calıstıgı iş yarım kaldıgı gibi, 15-20 kişinin de hepsi hatayı düzeltmedigi sürece hepsi beklerle sap gibi..

O yüzden hashtable gibi structure alırlar bu tür fonksiyonlar. parametreleri koyup/çekmek içinde gerekli "keyword"ler development ortamında dökümantasyonla bildirilir.

Aslında ilk basta kimsenin aklına gelmeyecegi bir sorun ama 300 kişilik bi firmada çalışıosanız bütün bunları zamanla yaşar görürsünüz.

Sizin mantıgınızda hastable kullanırsanız performans kaybı olur. Hem memoryden hem de zamandan. Ama bütün bunlar önemsenmeyecek düzeydedir. Yukardaki örnekte tartıştıgımız gibi..

[Bu mesaj Ceday tarafından 11 Eylül 2005 15:50 tarihinde değiştirilmiştir]

[Rahan]

ilk aklıma gelenleri sıralayayım;
hashtable veya benzeri bişi kullanıldığında sorun çıkartmayan bir durumda, function overloading de sorun olmaz.

fonksyona gönderilecek hashtable ın eksiksiz olduğu nerde kontrol ediliyor? runtime da sırf parametre hatası için kontrol mü yapılıyor? bu da performans kaybı değil mi?

fonksyonun yeni versiyonu için sonuna Ex gibi bir eklenti getirmek daha makul değil mi?

ha bi de en önemlisi bunların ip yi long olarak tutmakla arasındaki bağıntı ne??
[signature][hline]pppppt.. kediler çorba içmezki!

[Bu mesaj Rahan tarafından 11 Eylül 2005 16:39 tarihinde değiştirilmiştir]