Hi everybody,


I am working under Solaris 2.6

I developped an application which connect to the "External Company" network.

In order to connect to this remote network, I am using the "External Company" 
API.

Of course, I do not administrate the "External Company" network and I do not 
have the API sources.

I would like to simulate a network disconnection without physically removing the 
network cable.

I can identify the connection with "netstat -a" so my question is :

=> Is there a Unix command which could force the socket to close (which would 
simulate a disconnection) ?


Thanks in advance for your help.



Paul



-- 
Ce message a ete poste via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr

http://forums.club-internet.fr/

> ifconfig hme0 down

> .... you'd better be on the console tho...


Thanks for the command.

I was expecting a softer way to close the socket (I am not the only person 
working on this Unix host)

Is there any socket-oriented close command ?


Paul

-- 
Ce message a ete poste via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr

http://forums.club-internet.fr/

Paul LAURENT <pl@nospam.com> writes:

> > ifconfig hme0 down
> 
> > .... you'd better be on the console tho...
> 
> 
> Thanks for the command.
> 
> I was expecting a softer way to close the socket (I am not the only
> person working on this Unix host)
> 
> Is there any socket-oriented close command ?

You'd have to find out which process has the port open, and kill that
process. Depending on your system, try lsof, fuser, or whatever the
system has to show you that.

Joe

In article <m34r23znla.fsf@invalid.address>,  <joe@invalid.address> wrote:
>Paul LAURENT <pl@nospam.com> writes:
>
>> > ifconfig hme0 down
>> 
>> > .... you'd better be on the console tho...
>> 
>> 
>> Thanks for the command.
>> 
>> I was expecting a softer way to close the socket (I am not the only
>> person working on this Unix host)
>> 
>> Is there any socket-oriented close command ?
>
>You'd have to find out which process has the port open, and kill that
>process. Depending on your system, try lsof, fuser, or whatever the
>system has to show you that.

I think he's trying to test the application's reaction to losing the
socket, so I doubt that killing the process would be useful for this
purpose.

-- 
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

>> You'd have to find out which process has the port open, and kill that
>> process. Depending on your system, try lsof, fuser, or whatever the
>> system has to show you that.

> I think he's trying to test the application's reaction to losing the
> socket, so I doubt that killing the process would be useful for this
> purpose.

Yes, you are right => I do not want to kill my client process since I want to 
test its ability to reconnect after a socket connection loss.

I know that I can shutdown the network interface but all the other people 
connected on the same Unix workstation will not be really happy !

I suppose that the socket connection is flagged "active" or "inactive" somewhere 
in the Kernel (this is the information we get with the "netstat" command) so 
there should be a way to force the socket to close by writing something 
somewhere in the Kernel.


PL

-- 
Ce message a ete poste via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr

http://forums.club-internet.fr/

On Thu, 03 Jul 2003 18:56:55 +0000, Paul LAURENT wrote:

> Yes, you are right => I do not want to kill my client process since I
> want to test its ability to reconnect after a socket connection loss.

In that case you don't want to "close" the socket. That would result in
the next read()/recv() or write()/send() returning zero to indicate the
connection has been closed. From your description it sounds like you
are trying to test the behavior of your application when an unexpected
failure occurs (e.g., the network connection is lost or the remote
host dies).

In any case the best solution is the one proposed by Mr. Halpin: use a
proxy server. You can then program the proxy server to mimic any failure
mode that is of concern. I've read about proxies that can be used in
exactly this way but don't recall any product names. Try posting to
the comp.protocols.tcp-ip group.

> I suppose that the socket connection is flagged "active" or "inactive"
> somewhere in the Kernel (this is the information we get with the
> "netstat" command) so there should be a way to force the socket to close
> by writing something somewhere in the Kernel.

Whoa! I'm a level three kernel support engineer who examines kernel crash
dumps and writes kernel fixes. Even if there were an easily determined
word of memory whose value could be changed atomically which would
"close" a socket I would hesitate to do so. It would be far to easy
to alter the wrong location and cause random data corruption or other
inexplicable behavior for the system as a whole. In any event it is
extremely unlikely that it can be done by poking a new value into some
kernel virtual address. That certainly isn't the case for the two Unix
implementations I support.

> From your description it sounds like you
> are trying to test the behavior of your application when an unexpected
> failure occurs (e.g., the network connection is lost or the remote
> host dies).

That's it : I want to test my program when an unexpected network event occurs 
but I am not the remoter server administrator (it is administrated by another 
company) so I can not kill the server process.

I will use a proxy server (like you and the other people suggested)


> Even if there were an easily determined
> word of memory whose value could be changed atomically which would
> "close" a socket I would hesitate to do so.

I did not really want to modify the kernel : I supposed that the socket state 
was probably flagged somewhere in the kernel so a system command which modify 
the socket state could exist.


Thanks for your help.
-- 
Ce message a ete poste via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr

http://forums.club-internet.fr/

In article <200374-94240-871071@foorum.com>, pl@nospam.com says...

> I will use a proxy server (like you and the other people suggested)
> 
I'll give you another (better?) suggestion:

Create a layer between your app and the socket-functions.
Some kind of #define send sendX
This could also be done by some linker magic, but I can't give you an 
example here.
So you will be able to simulate _all_ return values and error conditions 
at the interface, even those which will not occur on your current 
system. Even undefined OS-behaviour.
Additionally, this errors could be easily made configurable / 
scriptable. This will provide you basics for automated testing.

Also, it may be easier than creating a proxy, which has only limited 
possibilities.

Regards,
Michael B.

On Mon, 07 Jul 2003 17:27:31 +0200, Michael Bruschkewitz wrote:

> In article <200374-94240-871071@foorum.com>, pl@nospam.com says...
> 
>> I will use a proxy server (like you and the other people suggested)
>> 
> I'll give you another (better?) suggestion:
> 
> Create a layer between your app and the socket-functions. Some kind of
> #define send sendX This could also be done by some linker magic, but I
> can't give you an example here.  So you will be able to simulate _all_
> return values and error conditions at the interface, even those which
> will not occur on your current system. Even undefined OS-behaviour.
> Additionally, this errors could be easily made configurable / scriptable.
> This will provide you basics for automated testing.

For this particular requirement your recommendation is going to be more
work than setting up a proxy server. Simulating the behavior of the TCP
stack (and the operating system in general) is going to be difficult,
to say the least. Plus, it doesn't provide any mechanism for simulating
network failures in the reverse direction. Simply simulating a graceful
session shutdown (e.g., such as would happen if close() were called) can
be handled by the mechanism you suggest. General failures (e.g., network
failures or the remote host crashing) can be simulated in theory by such
a mechanism, but not in practice. There are timing/retransmission issues
involved that you'll have a hard time simulating. It's much easier with
a "man in the middle" that can alter the TCP/IP data stream passing
between the two hosts (e.g., by dropping packets).