17. oktober 2007 - 13:12Der er
16 kommentarer og 1 løsning
identificere netværkskort baseret på ipadresse i netværket
Hvis jeg har en computer med to netværkskort, og ønsker at finde ud af hvilket netværkskort der er på det netværk hvor jeg kender en specifik IP Addresse på en anden computer, kan det så lade sig gøre i C# og .NET.
Scenariet kunne være at min computer har ip 1.1.1.1 på netværksadapter A og 2.2.2.2 på netværksadapter B. Jeg kender maskinen 3.3.3.3 som kan pinges fra kommandoprompten, men kan man identificere om det er A eller B der er på samme netværk som 3.3.3.3
System.Net.NetworkInformation ... der burde være en masse idder til at måske få det til at virke .....
Må man spørge i den sammenhæng du skal vide hvad netkort den bruger?
Jeg ville nok starte med at teste om den overhovedet er på det lokale net, ved at lave en ipcalc ... og derefter se om hosten er i live hvis den er på samme net ...
hvis min computer med 1.1.1.1 er forbundet til en router der kender 3.3.3.3 kan det sagtens lade sig gøre. --"Må man spørge i den sammenhæng du skal vide hvad netkort den bruger?" Jeg forstår ikke helt dit spørgsmål.
Jeg har brug for at jeg fra maskinen 1.1.1.1 kan fortælle maskinen 3.3.3.3 min ipaddresse. Men hvis jeg har flere netkort i maskinen skal jeg kunne fortælle den en IP-addresse som den kan se, deraf problemstillingen.
hvordan fungere det med ipcalc, og hvordan vil du tjekke om den er i live? mener du med ping? hvis ja, så er det ikke acceptabelt da routere kan sættes op til at fjerne ping request.
jeg ved godt jeg skrev at man kan pinge oppe i det oprindelige spørgsmål, men det jeg leder efter er netværksadapter discovery mekanisme eller lignende. Det kan godt være det ikke kan lade sig gøre på andre måder end at lave en socket på maskine 3.3.3.3 min pc så kan forsøge at binde til henholdsvis 1.1.1.1 og 2.2.2.2, men ville helst undgå dette hvis der findes noget indbygget i .NET frameworket.
lav en tracert ... så kan du jo se hvad for en gateway den tager, og deraf kan du så se hvad for en af dine ip'er den har brugt ... og så ved du jo på samme tid også hvad netkort ....
Hvis du skal fortælle en pc hvad ip du har ... så kan du jo heller ikke hoppe igennem nogen router, da det så er den forkerte ip klienten vil få oplyst ...
Og du skal jo have noget på den anden computer (socket server måske), som lytter efter hvad ip du kommer fra ... med lidt auth ... eller ville det jo være nemt at hacke.
Hvis folk slår echo reply fra i routeren følger de ikke en RFC standard ... men ved godt mange gør det.
"Må man spørge i den sammenhæng hvorfor du skal vide hvad netkort den bruger?" ( det har du så svaret på nu ... )
Til sidst ... hvis jeg har forstået det rigtig ... så vil du fortælle en hvilken som helst ip i verden hvad ip du selv har ? ( da du angiver 2 net som ikke uden en router kan se hinanden ) for mig giver det igen mening ....
Jeg har to applikationer jeg laver. server applikationen er en besked router, som jeg skal lave et abbonentkald til. det vil sige jeg skal fortælle serveren hvilken addresse den skal aflevere beskeder til mig på. Jeg kan ikke garantere at der er DNS i setuppet, og den teknologi jeg er bundet af til at kommunikere med serveren gør at serveren på baggrund af mit request ikke kan se hvilken ip jeg har. Det betyder jeg er nødt til at vide hvilken ip jeg sender beskeden fra,i og med at teknologien også tager hånd om min afsendelse af beskeder og dermed abstraherer netværk væk for mig, da jeg har serverens IP. Jeg vil meget nødigt skulle lave socket lyttere på serveren til at finde ud af den salgs information med, så derfor ønsker jeg heller ikke at introducere en masse hacks for at løse problemet.
Buzzzz ved du om det er muligt at lave en trace route via .NET? Hvori jeg kan få den information omkring netkort ip'er osv?
Du vil sende din lokale ip til serveren ... men du siger faktisk allerede at serveren ikke må kende din eksterne ip ... så har du da et problem med at få data frem til din klient app .... ?
Ved ikke om du kan lave tracert fra .NET ... men du kan jo grap output fra commandline ....
Jeg siger ikke at serveren ikke må kende min ip, jeg siger bare at den underlæggende teknologi jeg benytter til at sende beskeder med ikke giver serveren mulighed for at se f.eks. IP på afsenderen af beskeden. Derfor er semantikken at man sender en besked til serveren om at man gerne vil abbonere på noget information og man vil gerne have informationen levere på en bestem ip. Herefter vil anden informatoin sendt til serveren blive forwardet til min klientapplikation.
Et ganske almindeligt distribueret publish subscribe pattern.
Jeg tror desvære jeg ikke er helt med hvordan det ville komme til at virke ... så jeg må bakke ud herfra ...
Min viden er selvlært ... så alt det pattern ting siger mig ikke noget ...
[Server Public Ip] --- [Internet] --- [Router Public Ip] --- [Klient Local Ip]
Sådan går jeg ud fra det ser ud ... derfor kan jeg ikke se hvad serveren skulle få ud af at kende den ip på klient pc'en hvis du laver forward på routeren ... jeg synes ligesom der er information jeg mangler for at forstå dit setup ...
og brug ikke underliggende teknologi "ordet" ... bare sig hvad der skal håndtere det ... eller er det selv opfundet protokol?
Jeg ville nok bare lave at klient er connected via socket eller noget til serveren konstant ... og så kan den jo nemt sende info tilbage ...
Kan ske arve_v kommer på ... hans hovede kan måske nemmere gennemskue hvad du er ude på :-)
Jamen hvis det kan gøre dig mere tilpas, så kan jeg fortælle at teknologien er MSMQ eller microsoft message queueing. den har forskellige måder at sende information, herunder ved hjælp af IP-addresser (FormatName:Direct=TCP) så klienten sender en besked til en kø på serveren. serverapplikationen lytter på køen, tager beskeden af og tolker beskeden, som indeholder information om hvilken data klienten ønsker, samt hvor klienten har en kø placeret som data skal puttes i. For at kunne bede serveren om at sende beskden til klientens kø skal serveren vide om det er FormatName:DIRECT=TCP:1.1.1.1\Private$\kønavn eller FormatName:DIRECT=TCP:2.2.2.2\Private$\kønavn
Derfor skal jeg, før jeg på klienten sender en besked til serverens kø, vide hvilken ipaddresse serveren skal lægge sine svar beskeder på.
Når man bruger MSMQ, så er det almindelig god skik at køerne man læser fra ligger lokalt. Da jeg ønsker et "Clean cut", hvor gode designprincipper følges, kan jeg desværre ikke løse problemet med metode nummer 2. Til at styre hvor serveren skal sende beskederne hen, har jeg produceret et xml skema, og noget xml som beskriver "kontrakten" for hvor data kommer fr og hvor de skal hen. Da jeg har et krav om at andre skal kunne integrere igennem formatet, er det desvære heller ikke rigtigt acceptabelt at man kan tage en mængde køer/destinationer som så skal prøves ved hjælp af trial and error. Jeg overvejer om den rigtige løsning består i at benytte den førstkomne IP-addresse, og så ellers eksponere IP-konfiguration igennem en konfigurationsfil så man kan overstyre hvis det forkerte valg er truffet af applikationen. Man kan jo dokumentere sig ud af meget, hvis man beskriver at i multi-netkort-setup skal man huske at tjekke op på konfigurationen. Hvis ikke der er andre forslag tror jeg det bliver løsningen.
Det ville bestemt også være den løsning jeg ville vælge, da jeg tvivler på at mange computere i dag har flere ip'er sat op ...
Grunde kan være der, men stadig meget tvivlsomme, og nok kun i udviklingsmiljøer jeg kunne se det smarte i det at have flere ip'er på forskellige ip net.
hvad for noget sjov? Er udviklingsmiljøer sjove eller ?
Miljøer ting skal bruges kommer selvfølgelig an på hvor man er henne, er hvad ens app skal kunne ... dit miljø er nok anderledens kan jeg forstå på dig.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
