Re: Re-use an address/port when binding a socket used for Sending data

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Well, for our purposes, we may consider the "packet" that I am sending to be
a short stream of data.

I am sending the stream to "punch" a TCP/IP "hole" to enable peer-to-peer
communication behind certain well-behaved routers. About 60% of routers
deployed today will respond to this technique; for the remaining 40% you
must fall back to a port-to-port relay server to achieve true disovery and
TCP/IP communication between peers that can communicate with a common
rendezvous server but each lie behind NAT'ted firewalls . You can learn
about this hole punching technique by reading section 4 of the excellent
paper at http://www.brynosaurus.com/pub/net/p2pnat/ -- it is widely used and
well-understood.

However, it requires that I periodically send a short stream from a known
local port. Hence I need to bind to a local port, send the stream, close
the socket, then re-bind a little while later (perhaps 30 seconds later).

Thanks!

-- Greg

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:%23sbeZ19WFHA.3540@xxxxxxxxxxxxxxxxxxxxxxx
> Gregory Hassett wrote:
> > Hello,
> >
> > I want to periodically send a TCP packet to a peer, always from the
> > same source port.
>
> TCP is a stream protocol. It has no packets at least as far as TCP users
are
> concerned. If you need to periodically send something you open TCP stream
> and periodically write data to it.
> Perhaps if you would tell what you are trying to accomplish it would be
> possible to suggest some better way to do it.
>
>
> --
> Eugene
> http://www.gershnik.com
>
>


.

Relevant Pages

  • Re: RFC: Latency reducing TCP modifications for thin-stream interactive applications
    ... provoke high latencies when using TCP is unfortunate. ... preempt the experience of packet loss. ... FASTER Fast Retransmit: Instead of waiting for 3 duplicate ... These enhancements are applied only if the stream is detected as ...
    (Linux-Kernel)
  • Re: video compression (mjpeg)
    ... ONLY when there is CRC error is a slow down as re-request and packet is= ... I have been thinking about NFS: they switched from UDP to TCP. ... In case of recording they want an intact stream. ... There is some redundancy in TS streams, ...
    (comp.os.linux.development.apps)
  • Re: Reliability of Java, sockets and TCP transmissions
    ... TCP gives you a data *stream*. ... are packet based and your data will be sent in chunks that bear little ... the first two times but only 436 bytes the third time, ...
    (comp.lang.java.programmer)
  • Re: problem with DES (Data Encryption Standard)
    ... I considered that but it doesn't work well with a "stream" of data. ... But that's what padding is for. ... TCP sockets have the unfortunate ... send you a simple "packet" of data. ...
    (comp.lang.tcl)
  • Re: video compression (mjpeg)
    ... the compression is BAD and unsuable for VOIP over low bandwidth links. ... AFAIK TCP is not a good choice for applications that need data with low ... If I send a TCP stream, AND THE LINK HAS NO ERRORS then things happen real fast. ... ONLY when there is CRC error is a slow down as re-request and packet is re-sent. ...
    (comp.os.linux.development.apps)