socket problem?

David Bolen db3l at fitlinxx.com
Tue Sep 12 18:13:30 EDT 2000


Zajcev Evgeny <lg at localhost.rgz.ru> writes:

> I dont want to use socket allready connected to some host:port

But that's what the protocol TCP is - a stream protocol which
establishes a connection, then manages a stream of data over that
connection, and then tears down the connection.  I think there may be
some basic mis-understanding as to what TCP is doing.

> I just need to send 1 tcp/ip packet to someone(i generate this
> packet according tcp/ip protocols)

There's really no such thing as sending one TCP packet to someone.  To
send any data under control of TCP you first form a connection to the
remote connection point (which is identified by host and port) - this
very process involves several "packets".

Once you have the connection, you can send any amount of data - the
data may be broken into independent IP packets beneath the scenes (TCP
runs over IP) but at the TCP layer there really isn't a concept of a
packet - it's just a stream of data.  When you're done sending, you
close the connection.

TCP as a protocol is built to ensure that the data you send reaches
the other side in the same order that you transmitted it.  To do this,
it may retransmit data, and has to manage the connection between the
two endpoints.  So you must initially form the connection - after that
you can request data be transmitted, but you have no real control over
the underlying IP packets - TCP sends them as needed to get your data to
the other end of the connection.

> i've mistaken in my previos post
> i dont assign port that socket use to connect
> but when i do it right i got
> that when i try to sendto(packet, (host, port)) my packet appended
> as tcp data field and all IP and TCP headers generated automaticly
> similary to send(packet) in allready connected socket

Well, the TCP and IP headers will always be automatically generated by
the underlying protocol system no matter how you inject your data
(which is placed in the payload of the protocol).

But for a connection oriented protocol (TCP is a connection oriented,
stream protocol, while something like UDP is connectionless, and
datagram oriented), the sendto() function is the same as the send()
function - any addressing information should be ignored as the socket
will already have been connected to the remote session.

> before it i think that sendto doesnt invoke any ip encoding,
> just put it with transmition module.

To some extent, yes, both send() and sendto() just pass on their data
to the underlying protocol to be encapsulated within any appropriate
header information necessary.  sendto() has the added ability to
communicate new address information for connectionless protocols (like
UDP) that are not fixed to a single endpoint.

If what you really want to do is send a small fixed amount of data to
a remote endpoint using TCP, you must:

  * Grab a socket (socket)
  * Bind it locally (bind).  This makes it usable as an endpoint of
    communication.
  * Connect the socket to the remote endpoint (connect)
  * Send the data (send or sendto)
  * Close the socket (shutdown/close)

This process is repeated for new connections.

If what you want to do is truly send a single datagram to a remote
endpoint, then you need to use a datagram protocol such as UDP, in
which case you could simplify the above to:

  * Grab a socket (socket)
  * Bind it locally (bind)
  * Send the data to any location (sendto)

and repeat the sending to other locations with the same socket.

Which approach is appropriate depends on the nature of the data, and
if there are specific requirements from the other party you wish to
communicate with.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list