App needs two-way communication with TCL 1

[zombieZero]

Sorry if this is daft, but basically my situation is this:

I've written a protocol tester in ITCL that our TCL harness here utilizes via a series of test scripts. I'm working with someone else in another group who has come up with a test creator, and we want to make the two work together.

I think socket is the way I want to go but every time I try and use a variant of that I either get a permission denied or a connection refused...I admit I'm not sure if this is even the correct way to go.

Has anyone else out there ever done this who can offer up some guidance to a newcomer? It would be easiest if the test creator could telnet to a certain socket, feed the commands over it, and then field the responses that come back from my piece.

 

[Bong]

Well, I don't know anything about iTCL, but I've done a few client/server apps using sockets with plain TCL. It should be the same. Since you didn't post any code, I can't tell if what I'm about to say is known to you already, but here goes. In a client/server application, you need one program to act as the server,

socket -server <command name> <port>

where <command name> is a proc that will be invoked when a client connects.

Then, the other program needs to have a client socket,

set s [socket <host> <port>]

The proc, <command name> should be the read, or write, to the socket, and the client should write or read to $s.

It's all explained here>

http://wiki.tcl.tk/1114

_________________
Bob Rashkin

 

[zombieZero]

Thanks, that got me started...basically I have this test harness and I'm building an Interpreter to talk between the remote app and mine. In the Interpreter's constructor, I do this:

set socketName [socket -server interpret 5678]

'interpret' is a method that is part of the Interpreter class.

Right now, just to get some kind of small test going, the ::interpret method just looks like this:

itcl::body Interpreter::interpret {args} {

puts "ARGS WERE: $args"

}

Eventually, the remote app will telnet in on port 5678, and send information to the interpreter which will then take the input and translate it into commands my piece understands. When I try and telnet in on that port, however, I get this error:

Error: bad flag "sock10": must be -eof

Do you know what I might be doing wrong..?

Thanks.

 

[Bong]

I'm not sure "telnet" is usable as a client in this case. What language is your client written in? Can you just open a socket without "telnet"?

_________________
Bob Rashkin

 

[zombieZero]

Thanks for your responses - I see about the telnet...I just open a socket now and that part seems to work. Basically, I need his app to send mine commands and I will execute them in my environment and send back the results.

I use the command:

socket -server interp 5678

Where, just to test, interp looks like this:

proc interp {chan ip port args} {

puts "CHAN: $chan"
puts "IP: $ip"
puts "PORT: $port"
puts "ARGS: $args"
eval $args
puts $chan "DONE"

}

...and the remote app sends:

MsgBox(fSocketTransmission("10.1.161.23","5678","master0 dumpInfo"))

The message doesn't seem to come down though. Maybe this now lies outside of TCL, I'm not sure. When the command is sent, the interp proc responds:

CHAN: sock10
IP: 134.141.97.175
PORT: 4755
ARGS:

Then the sender complains it timed out because it never gets an EOF I think. Is there something else I need to do to allow the flow of messages back and forth?

 

[Bong]

This may be outside Tcl. What language is the client in? What "args" is "eval args" working on?

Anyway, just for jollies, try writing the client in Tcl, just to make sure all your pipes are clear. Change your proc, interp, to just read the channel (socket). When the client connects, the server calls interp with 3 automatic arguments, the first of which is "channel". Inside "interp" you should gets $channel or some such. Once that works for you, you'll need to explore the syntax peculiarities of the client in whatever language it's written.

_________________
Bob Rashkin

 

[Bong]

Something like this should work.

#server app
proc srvTest {chan cadd cport} {
     puts [gets $chan]
     close $chan
}
socket -server srvTest 8888
vwait forever

#client app
set s [socket localhost 8888]
puts $s "this is a test"
flush $s
close $s

If it does, then we can look at what your client is doing. If not, then we've got bigger problems.

_________________
Bob Rashkin

 

[zombieZero]

That, combined with a little tweaking from the vbs guy working on the client app, seems to have done it. Thanks for the help, I got handed this and (clearly) didn't really even know where to start. We actually got a successful test to work where his side initiated the test over the socket, I ran it, then sent back the results which his app interpreted.

Thanks again!