[Python-talk] A few more socket related questions

[Ben Scott]

On Fri, Aug 28, 2009 at 12:05 PM, <bruce.labitt at autoliv.com> wrote:
> Using TCP, How would one send a large array >> MTU ?

  Just write the data to the socket.  The TCP implementation handles
the details.

> When it comes down to it, what is the real advantage of tcp?

  TCP is reliable, two-way, connection-oriented, and stream-oriented.
TCP acts like a pipe: You put data in one end, it comes out the other,
in the same order you put it in.  Actually a pair of pipes, flowing in
opposite directions.

  UDP is unreliable, connectionless, one-way, unsequenced, and
datagram-oriented.  UDP is more like a bunch of postcards, which might
get delivered in any order, or not at all.

> The socket.send documentation still says to check the return value for the
> number of bytes sent...  Is it just that tcp keeps trying to send?

  As I recall, for TCP, the send(2) call will block if you try to send
more data than will fit in the transmit buffer, and won't return until
TCP has consumed all the data you gave it.  I think UDP just returns
an error.

> As I understand it, in tcp the client has to create and destroy a
> socket(s) for each transaction.

  TCP and UDP do not recognize a concept of "transaction".

  For UDP, you create the socket, connect() it, and send data.  UDP
has no idea if the destination host is even there.  I suppose you
could call each datagram a "transaction", but UDP does not provide the
semantics usually associated with the word "transaction".

  For TCP, you create the socket and connect() it.  If the network
subsystem can establish the connection with the remote host, the
connect() succeeds.  You can then send/receive as much data as you
want.  You can create more sockets to the same host, or just keep
using the same one; that's up to you.

  If you want to impose transactions upon that TCP single stream, you
can, but it's sometime you (or a library) has to do; it's not provided
by TCP.  You could create, connect, and teardown a TCP connection for
each transaction, but that's higher overhead.  Most people either use
a library, or just implement their own simply scheme.  For example,
use an end-of-data marker.  That could be newline if it's all ASCII
without formatting.  If it's arbitrary binary data, begin each
transaction with a header that indicates the length.

  There is a socket type for sequenced reliable packets, but I don't
think IP normally supports it.

> How does the client know if all the data is sent?
> How does the server know it got everything?

  TCP and UDP do not recognize a concept of "client" or "server".
There are sender and receiver.

  For UDP, the send() call is atomic, and will either send or return
error.  As noted, you have no way of knowing if it made it to the
receiver.  The receiver has to already be listening for it.

  For TCP, handshaking, flow control, acknowledgment and
retransmission are built-in.  When the connection is set-up by the
sender, it tries to contact the other end, which has to be listening
for new TCP connections.  If not, the connect() will fail.  As I
recall, once the TCP connection is up, the send() call may return an
error if the network layer has detected a problem with the other end
(timeout, excessive errors, etc.) and was blocking anyway.  If the
call wasn't blocked, the network layer will send SIGPIPE to the
process.

> Can the server send data to the client without a request?  (Delayed
> output?)

  You'll have to clarify the above.  I suspect you're assuming
semantics that TCP and UDP do not provide.

-- Ben