[.NET] IP Adres uit TcpClient halen

[Verwijderd]

Ik ben een servertje aan het bouwen met een TcpListener. Zodra er een connectie geaccepteerd wordt maak een nieuw thread aan en geef een TcpClient object mee. Nu zou ik graag willen weten van welk IP deze connectie komt (op zich geen rare eis lijkt me). Alleen is er geen enkele manier te vinden om dit te doen.

Ik heb wat op Google gezocht en vond een "oplossing" in Managed C++. Ikzelf werk in C# en zou toch zeggen dat het daar ook in moet kunnen. Ik heb het voorbeeldje omgezet naar C# en zit nu met een vrij logisch probleem. In C++ kun je kennelijk elk object naar elk ander object casten ookal zijn ze niet van hetzelfde type (of subclasse daarvan). In C# kan dit niet bij mijn weten.

Een truuc om bij het IP adres van een NetworkStream to komen is dit (vertaald van C++ naar C#):

code:

class OpenNetworkStream : NetworkStream {
   public OpenNetworkStream(Socket s) : base(s) { }

   public Socket MySocket { get {return this.Socket; } }

   public string IPAddress {
      get {
         return this.Socket.RemoteEndPoint.ToString();
      }
   }
}

In het C++ voorbeeld wordt nu dit gedaan:

code:

NetworkStream * networkStream = pTcpClient->GetStream(); 
MyNetworkStream * myStream =  static_cast<MyNetworkStream *>(networkStream);

Een static cast, iets dat C# niet ondersteund naar mijn weten. Als ik dit probeer:

code:

OpenNetworkStream stream = (OpenNetworkStream)tcpclient.GetStream();

Geeft dit een CastingException, uiteraard.

Maar ja, hoe moet het dan wel? Iemand een idee?

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 14:18:

In het C++ voorbeeld wordt nu dit gedaan:

code:

NetworkStream * networkStream = pTcpClient->GetStream(); 
MyNetworkStream * myStream =  static_cast<MyNetworkStream *>(networkStream);

Een static cast, iets dat C# niet ondersteund naar mijn weten. Als ik dit probeer:

Dit is toch geen managed C++ ?
Kan je met pointers werken in managed C++?

code:

OpenNetworkStream stream = (OpenNetworkStream)tcpclient.GetStream();

Geeft dit een CastingException, uiteraard.

Kun je geen MyTcpClient class maken die overerft van TCPClient en die GetStream functie overload?

[Verwijderd]

whoami schreef op 10 oktober 2002 @ 14:25:
[...]

Dit is toch geen managed C++ ?
Kan je met pointers werken in managed C++?

Ja, dat kan, kan ook in C# trouwens (unsafe code).

[...]


Kun je geen MyTcpClient class maken die overerft van TCPClient en die GetStream functie overload?

Als je goed kijkt is dit ongeveer zoiets, alleen zit je dan met precies hetzelfde probleem. Je krijgt een TcpClient binnen met tcpListener.AcceptTcpClient(); Je moet de gekregen TcpClient dan ook op een een of andere manier naar jou eigen afgeleide TcpClient zien te casten om bij de protected properties te kunnen komen.

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 14:33:
[...]

Ja, dat kan, kan ook in C# trouwens (unsafe code).

Ik weet dat het kan, maar m'n vraag was of dat kon in managed C++. En unsafe code is geen managed code, vandaar.
Hiermee is m'n vraag ook alweer beantwoord: pointers kunnen niet in unsafe/unmanaged code.

Als je goed kijkt is dit ongeveer zoiets, alleen zit je dan met precies hetzelfde probleem. Je krijgt een TcpClient binnen met tcpListener.AcceptTcpClient(); Je moet de gekregen TcpClient dan ook op een een of andere manier naar jou eigen afgeleide TcpClient zien te casten om bij de protected properties te kunnen komen.

Aangezien jouw class afgeleid is van de NetworkStream class, kun je dan niet hetvolgende doen:

code:

NetworkStream ns = TcpClient.GetStream();
MyNetworkStream mns = (MyNetWorkStream)ns;

[Verwijderd]

hier stond onzin

[Verwijderd]

Verwijderd schreef op 10 oktober 2002 @ 14:18:
Als ik dit probeer:

code:

OpenNetworkStream stream = (OpenNetworkStream)tcpclient.GetStream();

Geeft dit een CastingException, uiteraard.

whoami schreef op 10 oktober 2002 @ 14:36:

code:

NetworkStream ns = TcpClient.GetStream();
MyNetworkStream mns = (MyNetWorkStream)ns;

Dat is dus een beetje precies wat ik geprobeerd heb

[Stimpy001]

Ik zat toevallig met hetzelfde probleem alleen dan met VB .NET. En ik kom er ook niet uit.

Ook een server met een TCPListener die zodra er een connectie geaccepteerd wordt een nieuw thread aan maakt en hierbij een TcpClient object mee geeft.

[Verwijderd]

Dat is toch vreemd op zich, zo iets elementairs

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 15:05:
Dat is toch vreemd op zich, zo iets elementairs

Wat gebeurt er als je die NetworkStream naar een object cast en dat object daarna naar een MyNetworkStream?

[Verwijderd]

whoami schreef op 10 oktober 2002 @ 15:08:

[...]

Wat gebeurt er als je die NetworkStream naar een object cast en dat object daarna naar een MyNetworkStream?

Dat kan ik natuurlijk wel proberen maar gaat toch fout. Elk object behoudt zijn type, en de typechecker zal daar ook op controleren (dat is ook een van de "voordelen" van een runtime omgeving, daar is dat mogelijk).

[Verwijderd]

Toen ik ooit eens een server<->client projectje gedaan heb, gebruikte ik de tcplistener om te wachten op clients .. iedere keer als een client een connectie legde met de server, accepteerde de server de connectie en maakte een nieuw object die voor de communicatie met die client zorgde.. zo kon je dus meerdere clients op 1 moment hebben.

Clients 'accepteerde' ik op deze manier:

C#:

Socket s = myListener.AcceptSocket();
Client c = new Client(s);

Client is een object waar ik voor de communicatie met een client zorg. In deze class had ik vervolgens een property 'IPAddress' gemaakt, die de RemoteEndPoint van de socket als string terug gaf.

[Verwijderd]

Verwijderd schreef op 10 oktober 2002 @ 16:21:
Client is een object waar ik voor de communicatie met een client zorg. In deze class had ik vervolgens een property 'IPAddress' gemaakt, die de RemoteEndPoint van de socket als string terug gaf.

Probleem is dat ik gebruik wil maken van een TcpClient, zodat ik op een redelijke manier (zonder al te veel gedoe) data kan sturen en ontvangen. En dat gaat met de Socket klasse nogal onhandig.

[Twilight Burn]

De TcpClient lijkt iets dat zonder veel gedoe data kan sturen en ontvangen, maar deze klasse is wel dermate gelimiteerd dat je uiteindelijk toch een hoop "gedoe" nodig hebt om alles werkend te krijgen zoals je wilt.

[Stimpy001]

Twilight Burn schreef op 10 oktober 2002 @ 18:42:
De TcpClient lijkt iets dat zonder veel gedoe data kan sturen en ontvangen, maar deze klasse is wel dermate gelimiteerd dat je uiteindelijk toch een hoop "gedoe" nodig hebt om alles werkend te krijgen zoals je wilt.

Hier ben ik het helemaal mee eens. Vaak ben je al weer genoodzaakt om een derived class te maken om zo de tekortkomingen van de TcpClient op te vangen. Uiteindelijk heb je dan vaak nog zelf een class oftwel een object geschreven

[Verwijderd]

Dan zit er niet veel meer op dan zelf een Socket wrapper te schrijven die doet wat ik wil

[Twilight Burn]

Stimpy001 schreef op 10 oktober 2002 @ 19:14:
[...]

Hier ben ik het helemaal mee eens. Vaak ben je al weer genoodzaakt om een derived class te maken om zo de tekortkomingen van de TcpClient op te vangen. Uiteindelijk heb je dan vaak nog zelf een class oftwel een object geschreven

Zo ver ben ik geneens gegaan, ik heb het eea geprobeerd, maar op een gegeven moment heb ik het maar opgegeven en ben ik met de Sockets verder gegaan, ik kreeg het namelijk niet voor elkaar om op de een of andere manier te detecteren of de verbinding er nog wel is. (En aangezien ik een verbinding maakte met een IRC server, wil het nog wel eens voorkomen dat je verbinding ineens weg is)

Ik snap zelfs niet waarom ze die TcpClient erin hebben zitten, hij is namelijk veel te beperkt om er iets fatsoenlijks mee te kunnen.