> After LAN is no accessible, the client cannot connect to the server

"Sergey Radkevich" <sergeyr@axiomatex.ru> wrote in message
news:uIKbYvrUFHA.2700@TK2MSFTNGP12.phx.gbl...
> > After LAN is no accessible, the client cannot connect to the server
> anymore (note that they are on the
> same machine!). When the cable is reinserted, the connection works again!
>
> One possible solution is to install loopback network adapter.
>
>

> > > After LAN is no accessible, the client cannot connect to the server
> > > anymore (note that they are on the
> > > same machine!). When the cable is reinserted, the connection works
again!
> > One possible solution is to install loopback network adapter.
> - So I guess that's not a bug, but it is predictable, right?

> - now everybody that uses my programs which are affected by this have to
> manually install this loopback adapter?

> - what's the best IP address to set for the loopback adapter and how do I
> determine this in each case?

> - you said this is one possible solution.. what would be the others?

> Spasiba! :)

> > When you install loopback adapter you can specify any address manually,
> > or use automatically configured ip address

> I have to specify it manually, so the client at the machine with the
server
> can reference the server through this address.. it only works then (I
tried
> it). if I continue to reference it with the machine name or "localhost",
> then it continues to produce the same behaviour no matter that the
loopback
> is present.

> After the problem happens, I can still get the prompt
> although I cannot connect to the server with my client.

> It happened on anothe machine..
> so it is definitelly not the problem just with my machine!

> Kakva pozivljajete?

> oh yes, I will learn russian some day :))

"Sergey Radkevich" <sergeyr@axiomatex.ru> wrote in message
news:%239xZdU5UFHA.1404@TK2MSFTNGP09.phx.gbl...
> > > When you install loopback adapter you can specify any address
manually,
> > > or use automatically configured ip address
>
> > I have to specify it manually, so the client at the machine with the
> server
> > can reference the server through this address.. it only works then (I
> tried
> > it). if I continue to reference it with the machine name or "localhost",
> > then it continues to produce the same behaviour no matter that the
> loopback
> > is present.
>
> Currently I think we need to investigate Alex Passos's idea (about
incorrect
> name resolution)
>
> > After the problem happens, I can still get the prompt
> > although I cannot connect to the server with my client.
>
> The reason to check is following:
> at this moment telnet uses new name resolution scheme (which is occurs
after
> disconnection),
> but client still use old IP address (which was before disconnection)
>
> > It happened on anothe machine..
> > so it is definitelly not the problem just with my machine!
>
> It might be a problem with a whole network configuration
> (If you are in domain, then chances are good
> that for some aspects all machines behave in the same way)
>
> Please provide the following information at your page with problem
> description:
> - source code of client application
> - dump from "ipconfig /all" command
> - content of HOSTS file
> - dump from "route print" command
> - dump from "ping localhost" and "tracert localhost" commands in
> disconnected state
> (but "telnet localhost 45326" works so disconnection it is not a
problem)
> - dump from "nslookup" utility
>
>
>
>
> HOSTS file is located in "%SystemRoot%\system32\drivers\etc" for WindowsNT
> family
>
> The following types of problems can occur because of errors related to the
> HOSTS file:
> - The HOSTS file or the DNS server does not contain the particular host
> name.
> - The host name in the HOSTS file or in the command is misspelled or uses
> different capitalization.
> (Note: Host names are case-sensitive.)
> - An invalid IP address is entered for the host name in the HOSTS file.
> - The HOSTS file contains multiple entries for the same host on separate
> lines; if so, the first entry is the one that is used.
> - A mapping for a computer name-to-IP-address was mistakenly added to the
> HOSTS file (rather than LMHOSTS).
> - Last line should ends with carriage return symbol (see KB105998)
>
> The correct format of the file is the following: "IP Address" "Friendly
> Name"
> For example:
> 127.0.0.1 localhost # Remarks are denoted with a #.
>
> "ipconfig /flushdns" can be used to clear client name resolution cache
>
>
>
>
>
>
> Next thing to check is packet routing (route print)
>
> The resolved IP address is passed to the IP routing component. The routing
> component returns either a routing error because a route was not found for
> the destination IP address or the forwarding IP address and interface over
> which the packet is to be forwarded cannot be found.
>
>
>
>
>
>
> About channels I have found following quotes from various sources:
>
> There are various considerations while writing a channel. They include a
> balance of performance, scalability and implementation complexity.
> Performance of a shared memory implementation would be certainly better
than
> named pipes. But issues when synchronizing between between reader/writers
> could lead to scalibility concerns, especially with multiple clients.
Named
> Pipes provide good mix of both perf and scalability as compared to the TCP
> channel.
>
> Remoting in v2.0 of the framework is introducing a new IPC Channel meant
for
> x-proc communication on the same machine. It is based on named pipes and
> works on win2k based platforms (win2k, winxp, win2k3). It will provide
> better performance characteristics than the current TCP channel. It will
> also provide a way to control access to the underlying pipe, so that the
> server can limit the access to a specific group. As with the new TCP
channel
> it also supports authentication and impersonation of client identities.
>
> For Framework 1.1 you can try
>
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=43a1ef11-c57c-45c7-a67f-ed68978f3d6d
> (I have not tried it myself)
>
>
>
>
>
> > Kakva pozivljajete?
>
> Horosho, spasibo. Zavtra moj 27-j denx rozhdeniya :)
> Fine, thanks. I am going to celebrate my 27-th birthday anniversary
tommorow
> :)
>
> > oh yes, I will learn russian some day :))
>
> I visited your homepage and was amused by number of languages which you
are
> learning :)
>
>

"Sergey Radkevich" <sergeyr@axiomatex.ru> wrote in message
news:%2305onC0UFHA.3532@TK2MSFTNGP09.phx.gbl...
> > > > After LAN is no accessible, the client cannot connect to the server
> > > > anymore (note that they are on the
> > > > same machine!). When the cable is reinserted, the connection works
> again!
> > > One possible solution is to install loopback network adapter.
> > - So I guess that's not a bug, but it is predictable, right?
>
> I have just tried to reproduce it, and was unable to reproduce this
> situation
> (Connection always work with or without loopback adapter and with or
without
> network connection
> even if I unplug cable between calls to localhost server object)

> So, I was wrong in my assumption and don't know the real reason.
> Nonetheless loopback adapter may help (Have you tried it?)

> > - now everybody that uses my programs which are affected by this have to
> > manually install this loopback adapter?
>
> The installation process can be automated...
> But you are right - remoting should be easy to use, so probably a better
> solution exists.

> > - what's the best IP address to set for the loopback adapter and how do
I
> > determine this in each case?
>
> It is possible to configure loopback adapter in the same way as any other
> network adapters.
> When you install them you can specify any address manually,
> or use automatically configured ip address

> There is also exist ways to programmatically enumerate network adapters
from
> .NET,
> but for this task them should be choosen automatically.
>
> > - you said this is one possible solution.. what would be the others?
>
> It is possible configure another type of [nonstandart] channel which
doesn't
> use packets
> (in the internet there are examples of channels which use named pipes, raw
> files, shared memory and other mechanisms of interprocess communications)

> > Spasiba! :)
> Pozhalujsta! :)
>

> - you said this is one possible solution.. what would be the others?

"mdb" <m_b_r_a_y@c_t_i_u_s_a__d0t__com> wrote in message
news:Xns9652AA6609AF1mbrayctiusacom@207.46.248.16...
> "David Krmpotic" <david.krmpotic@no-no.si> wrote in
> news:jH4fe.11973$F6.2430364@news.siol.net:
> > - you said this is one possible solution.. what would be the others?
>
> Another possible solution, if you can wait for .NET 2.0, is to use the IPC
> channel instead of a tcp channel.
>
> -mdb

> I will hopefully have some time
> tomorrow and I'll update the info on my web page on what I know
currently..
> If nothing else, now I have a pretty good work-around with loopback
> adapter!!

"Sergey Radkevich" <sergeyr@axiomatex.ru> wrote in message
news:%235Ie1q1VFHA.2692@TK2MSFTNGP15.phx.gbl...
> > I will hopefully have some time
> > tomorrow and I'll update the info on my web page on what I know
> currently..
> > If nothing else, now I have a pretty good work-around with loopback
> > adapter!!
>
> You can use "localhost" and it should work with both local and remote
> clients,
> but I don't test it. (I beg your pardon for my english if I mislead your)
>
> ====
> I received your private mail, will answer a little bit later.
>
>