Keep socket connections open

[scot...@gmail.com]

I would like to run a TCL script that goes out and opens a socket
connection (telnet on port 23) on say 4 routers. So I'm logging into 4
routers. I would then like to execute another TCL script that sends
commands to each of the 4 routers. So I would store the socket
descriptors and then be able to use them later on. For example...

# in script 1
set sock [socket 1.1.1.1. 23]
set sock1 [socket 2.2.2.2 23]
set sock2 [socket 3.3.3.3 23]
set sock3 [socket 4.4.4.4 23]

# in script 2
fconfigure $sock -buffering line -blocking false
fconfigure $sock1 -buffering line -blocking false
fconfigure $sock2 -buffering line -blocking false
fconfigure $sock3 -buffering line -blocking false

puts $sock "show run" #assuming no username and password is required
puts $sock1 "show ip int bri"
puts $sock2 "show run"
puts $sock3 "show run"

# in script 3
close $sock
close $sock1
close $sock2
close $sock3

Is there a way to do this?? I am using this example to simplify the
problem. Later I will be executing large test scenarios where
configurations will need to be changed, so I need the socket
connections to stay open throughout the entire test.

Thanks!
Scott

[scot...@gmail.com]

[Arjen Markus]

Why separate scripts?

What you can do is:

- Store the initialisation and finalisation (opening the sockets and
closing them) in one source file,
preferrably putting all the code in procedures such as open_sockets
and close_sockets.
That source file may also contain the main code (see below).
- Store the test code (your script 2) in another one, you could source
that file, when the time comes

The main code would look pretty much like:

# Define the procedures we need ...
proc open_sockets {} {
...
}
proc close_sockets {} {
...
}

# main --

open_sockets

source testcode.tcl

close_sockets

(The sockets you open are stored in global variables for easy access)

Something along those lines would work, I think, or otherwise I
misunderstand
your question.

Regards,

Arjen

[Volker Hetzer]

scot...@gmail.com schrieb:

> I would like to run a TCL script that goes out and opens a socket
> connection (telnet on port 23) on say 4 routers. So I'm logging into 4
> routers. I would then like to execute another TCL script that sends
> commands to each of the 4 routers. So I would store the socket
> descriptors and then be able to use them later on. For example...

If you really *need* to execute the other scripts instead of just
sourcing them, do your own server that listens to some local ports.
Then other scripts can connect to your little server which then
accesses the socket connection.

Lots of Greetings!
Volker

[Cameron Laird]

In article <1140679896.2...@g44g2000cwa.googlegroups.com>,

.
.
.
Yes. What I understand of this description makes it sound like
something that many, many other people do successfully.

In your telnetting, you might encounter a password issue. If you
do--if you are in the situation at all that you know you can do some-
thing "by hand", but you can't figure out how to automate it because
the router "doesn't echo" or otherwise confuses issues--then IMMEDI-
ATELY ask for help with Expect <URL: http://wiki.tcl.tk/2?expect >.

[scot...@gmail.com]

I dont know if that would work. The functions would be fine for
opening and closing the sockets. Here is an example:

Script 1:
1 - source file with open_socket function
2 - call open_socket as many times as needed
3 - script 1 ends
*** Now, once that tcl script ends, all of my socket connections close.
That is what I'm trying to avoid.

So when i go and call script 2 as follows to do the following:
1 - source file with write_socket function
2 - call write_socket with what socket handle???
3 - script 3 ends.

The whole point is to run a script that goes out and opens these socket
connections, store the socket handles so other scripts can just go and
do write_socket { socket handle } . Your approach above won't work
because testcode.tcl is being run from the main script, which I would
not be doing.

I dont have an issue with the "server" echoeing back, so I dont have to
use Expect (like if i were to log into a UNIX server or something).

Thanks for the responses!!

[Bruce Hartweg]

scot...@gmail.com wrote:
> I dont know if that would work. The functions would be fine for
> opening and closing the sockets. Here is an example:
>
> Script 1:
> 1 - source file with open_socket function
> 2 - call open_socket as many times as needed
> 3 - script 1 ends
> *** Now, once that tcl script ends, all of my socket connections close.
> That is what I'm trying to avoid.
>
> So when i go and call script 2 as follows to do the following:
> 1 - source file with write_socket function
> 2 - call write_socket with what socket handle???
> 3 - script 3 ends.
>
> The whole point is to run a script that goes out and opens these socket
> connections, store the socket handles so other scripts can just go and
> do write_socket { socket handle } . Your approach above won't work
> because testcode.tcl is being run from the main script, which I would
> not be doing.
>

That's not the way sockets work. when you open a socket it is for that
process to use - if that process goes away - the sockets go away.
This is same for Tcl as it is for a C program, or any other script.

If you want to keep reusing the same sockets - it all has to be done in
the same process - i.e. one running script. The suggestion was for you
to package all your code so that th code from script 2 gets run in the
same process - i.e. your code can be seperated into duifferent files
but are all run in one instance of the interpreter.

Bruce

[Donal K. Fellows]

Bruce Hartweg wrote:
> That's not the way sockets work. when you open a socket it is for that
> process to use - if that process goes away - the sockets go away.
> This is same for Tcl as it is for a C program, or any other script.

Not quite. You can pass a socket to another program as stdin or stdout,
but Tcl doesn't currently support passing arbitrary numbers of channels
this way. Not that you normally want to either.

Donal.

[Bruce Hartweg]

You can do that if script 1 executes script 2 (but at that point, it
could also just source it into the current interp), but the OP wanted
to run one script - have it open a bunch of sockets and then exit, then
later run other scripts that use them.

Bruce

[Donal K. Fellows]

Bruce Hartweg wrote:
> You can do that if script 1 executes script 2 (but at that point, it
> could also just source it into the current interp), but the OP wanted
> to run one script - have it open a bunch of sockets and then exit, then
> later run other scripts that use them.

Oh. Sockets don't work that way on any platform (though daemons can
sometimes appear to operate in that manner).

Donal.

[jamshed]

I agree to Volker's suggestion.
Build a simpe Socket Connection Manager. Which can provide Open, Close,
Write Services.

Regards,
jamshed