Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

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:

How do we close normal sockets????

close $s

???

On 15 mei, 10:07, Aman <ama@gmail.com> wrote:

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:

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:

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:

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:

Please file a bug report at:

http://sourceforge.net/tracker/?group_id=13179&atid=113179

Mark

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc