|
|
 |
 |
 |
 |
TCL(Tool Command Language) Scripting
|
 |
 |
 |
 |
 |
 |
 |
 |
Release Socket
set port 12351 set s [udp_open $port] Hi, I am using the above given code to lock port "12351" can someone tell me what command should I use to release the port after its use is over??? Thanks Regards Aman jain
On 15 mei, 08:16, Aman <ama@gmail.com> wrote: > set port 12351 > set s [udp_open $port] > Hi, > I am using the above given code to lock port "12351" can someone tell > me what command should I use to release the port after its use is > over??? > Thanks > Regards > Aman jain
With the ordinary sockets (I do not know UDP) closing them is enough - but they are not automatically closed on exit (at least not on Windows). My guess: udp_close $s Regards, Arjen
On May 15, 12:37 pm, Arjen Markus <arjen.mar@wldelft.nl> wrote:
> On 15 mei, 08:16, Aman <ama @gmail.com> wrote: > > set port 12351 > > set s [udp_open $port] > > Hi, > > I am using the above given code to lock port "12351" can someone tell > > me what command should I use to release the port after its use is > > over??? > > Thanks > > Regards > > Aman jain > With the ordinary sockets (I do not know UDP) closing them is enough > - but they are not automatically closed on exit (at least not on > Windows). > My guess: udp_close $s > Regards, > Arjen
How do we close normal sockets???? close $s ???
On 15 mei, 10:07, Aman <ama@gmail.com> wrote:
> On May 15, 12:37 pm, Arjen Markus <arjen.mar @wldelft.nl> wrote: > > On 15 mei, 08:16, Aman <ama@gmail.com> wrote: > > > set port 12351 > > > set s [udp_open $port] > > > Hi, > > > I am using the above given code to lock port "12351" can someone tell > > > me what command should I use to release the port after its use is > > > over??? > > > Thanks > > > Regards > > > Aman jain > > With the ordinary sockets (I do not know UDP) closing them is enough > > - but they are not automatically closed on exit (at least not on > > Windows). > > My guess: udp_close $s > > Regards, > > Arjen > How do we close normal sockets???? > close $s > ???- Tekst uit oorspronkelijk bericht niet weergeven - > - Tekst uit oorspronkelijk bericht weergeven -
Yes, they behave as if they were ordinary files on disk (except for the fact that you have to close explicitly, at least on Windows). Regards, Arjen
On May 15, 10:23 am, Arjen Markus <arjen.mar@wldelft.nl> wrote:
> On 15 mei, 10:07, Aman <ama @gmail.com> wrote: > > On May 15, 12:37 pm, Arjen Markus <arjen.mar@wldelft.nl> wrote: > > > On 15 mei, 08:16, Aman <ama@gmail.com> wrote: > > > > set port 12351 > > > > set s [udp_open $port] > > > > Hi, > > > > I am using the above given code to lock port "12351" can someone tell > > > > me what command should I use to release the port after its use is > > > > over??? > > > > Thanks > > > > Regards > > > > Aman jain > > > With the ordinary sockets (I do not know UDP) closing them is enough > > > - but they are not automatically closed on exit (at least not on > > > Windows). > > > My guess: udp_close $s > > > Regards, > > > Arjen > > How do we close normal sockets???? > > close $s > > ???- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - > Yes, they behave as if they were ordinary files on disk (except for > the fact that you have to close > explicitly, at least on Windows). > Regards, > Arjen- Hide quoted text - >
Arjen, What do you mean by saying that the sockets have to be closed explicitly on windows? My sockets are closed when I exit the application on Windows XP. Mark
On May 15, 8:16 am, Aman <ama@gmail.com> wrote: > set port 12351 > set s [udp_open $port] > Hi, > I am using the above given code to lock port "12351" can someone tell > me what command should I use to release the port after its use is > over??? > Thanks > Regards > Aman jain
close $s Mark
On 15 mei, 12:13, Mark Janssen <mpc.jans@gmail.com> wrote:
> On May 15, 10:23 am, Arjen Markus <arjen.mar @wldelft.nl> wrote: > > On 15 mei, 10:07, Aman <ama@gmail.com> wrote: > > > On May 15, 12:37 pm, Arjen Markus <arjen.mar@wldelft.nl> wrote: > > > > On 15 mei, 08:16, Aman <ama@gmail.com> wrote: > > > > > set port 12351 > > > > > set s [udp_open $port] > > > > > Hi, > > > > > I am using the above given code to lock port "12351" can someone tell > > > > > me what command should I use to release the port after its use is > > > > > over??? > > > > > Thanks > > > > > Regards > > > > > Aman jain > > > > With the ordinary sockets (I do not know UDP) closing them is enough > > > > - but they are not automatically closed on exit (at least not on > > > > Windows). > > > > My guess: udp_close $s > > > > Regards, > > > > Arjen > > > How do we close normal sockets???? > > > close $s > > > ???- Tekst uit oorspronkelijk bericht niet weergeven - > > > - Tekst uit oorspronkelijk bericht weergeven - > > Yes, they behave as if they were ordinary files on disk (except for > > the fact that you have to close > > explicitly, at least on Windows). > > Regards, > > Arjen- Hide quoted text - > > > Arjen, > What do you mean by saying that the sockets have to be closed > explicitly on windows? My sockets are closed when I exit the > application on Windows XP. > Mark- Tekst uit oorspronkelijk bericht niet weergeven - > - Tekst uit oorspronkelijk bericht weergeven -
It is an impression I got from working with sockets: sometimes I would have to kill my program (it being a server thingy) and then for the next run I would need to open a socket with another port number. Uhm, am I confusing ports and sockets now? Anyway, that is the problem I was referring to. Regards, Arjen
Arjen Markus wrote: > It is an impression I got from working with sockets: sometimes I would > have > to kill my program (it being a server thingy) and then for the next > run > I would need to open a socket with another port number. Uhm, am I > confusing ports and sockets now? Anyway, that is the problem I was > referring to.
That's not a problem with the sockets not being closed. That's the way TCP is designed to work. The port number on a listener socket stays "reserved" for a certain number of seconds to prevent duplicate IP packets originally sent to the old listener from arriving after you've opened a new listener. UNIX does it too. There are ways to turn it off. SO_LINGER and SO_REUSEADDR address this. -- Darren New / San Diego, CA, USA (PST) His kernel fu is strong. He studied at the Shao Linux Temple.
On 15 mei, 15:36, Darren New <d@san.rr.com> wrote:
> Arjen Markus wrote: > > It is an impression I got from working with sockets: sometimes I would > > have > > to kill my program (it being a server thingy) and then for the next > > run > > I would need to open a socket with another port number. Uhm, am I > > confusing ports and sockets now? Anyway, that is the problem I was > > referring to. > That's not a problem with the sockets not being closed. That's the way > TCP is designed to work. The port number on a listener socket stays > "reserved" for a certain number of seconds to prevent duplicate IP > packets originally sent to the old listener from arriving after you've > opened a new listener. UNIX does it too. There are ways to turn it off. > SO_LINGER and SO_REUSEADDR address this.
Oh, that is completely new to me, but it makes sense! So it was just my interpretation of what was happening that was odd. Glad to know that. Regards, Arjen
We've encountered a problem while using a tcl TCP connection which has been converted to a spawn_id (so that the expect command can be used to parse the output). I haven't been able to construct a simple test program, so I'll have to explain it. Versions are expect-5.43, tcl8.4.12, SunOS 5.8. Simplified code would be something like this: catch {socket $server $port} serverSocket fconfigure $serverSocket -blocking 1 -buffering line spawn -noecho -leaveopen $serverSocket exp_send "exit\r" expect { eof { puts "got eof, and leaving" return "bleagh" } timeout { puts "timeout on command." } -re "prompt:" { puts "($spawn_id) gave prompt" } } On a random basis, about 1 in 20 tries, the closing TCP connection gets ECONNRESET at the read in ExpInputProc() instead of a nice bytesRead=0. This causes a nasty error exit instead of a call to the eof case. ExpInputProc() should have a few lines added to it so that it looks more like the TcpInputProc in tcl: TcpInputProc(instanceData, buf, bufSize, errorCodePtr) bytesRead = recv(statePtr->fd, buf, (size_t) bufSize, 0); if (bytesRead > -1) { return bytesRead; } if (errno == ECONNRESET) { /* * Turn ECONNRESET into a soft EOF condition. */ return 0; } -- * * Ed Attfield phone: 613-763-3102 * Nortel Networks email: attfi@nortel.com * * Unix is user friendly .. * It's just very choosy about who its friends are. * -- anonymous
On May 15, 4:00 pm, Ed Attfield <attfi@nortel.com> wrote:
> We've encountered a problem while using a tcl TCP connection which has > been converted to a spawn_id (so that the expect command can be used to > parse the output). > I haven't been able to construct a simple test program, so I'll have to > explain it. > Versions are expect-5.43, tcl8.4.12, SunOS 5.8. > Simplified code would be something like this: > catch {socket $server $port} serverSocket > fconfigure $serverSocket -blocking 1 -buffering line > spawn -noecho -leaveopen $serverSocket > exp_send "exit\r" > expect { > eof { > puts "got eof, and leaving" > return "bleagh" > } > timeout { > puts "timeout on command." > } > -re "prompt:" { > puts "($spawn_id) gave prompt" > } > } > On a random basis, about 1 in 20 tries, the closing TCP connection gets > ECONNRESET at the read in ExpInputProc() instead of a nice bytesRead=0. > This causes a nasty error exit instead of a call to the eof case. > ExpInputProc() should have a few lines added to it so that it looks more > like the TcpInputProc in tcl: > TcpInputProc(instanceData, buf, bufSize, errorCodePtr) > bytesRead = recv(statePtr->fd, buf, (size_t) bufSize, 0); > if (bytesRead > -1) { > return bytesRead; > } > if (errno == ECONNRESET) { > /* > * Turn ECONNRESET into a soft EOF condition. > */ > return 0; > } > -- > * > * Ed Attfield phone: 613-763-3102 > * Nortel Networks email: attfi@nortel.com > * > * Unix is user friendly .. > * It's just very choosy about who its friends are. > * -- anonymous
Please file a bug report at: http://sourceforge.net/tracker/?group_id=13179&atid=113179 Mark
|
 |
 |
 |
 |
|