[Python-talk] A few more socket related questions

[Lloyd Kvam]

On Fri, 2009-08-28 at 12:05 -0400, bruce.labitt at autoliv.com wrote:
> Thanks for peoples' observations at PySIG last night.  I heard folks 
> muttering why use UDP.  This got me thinking about my decision.  Maybe I 
> chose UDP for the wrong reasons.  So allow me a few questions...  Forgive 
> me if the questions are malformed, I really don't understand this stuff 
> yet.
> 
> Using TCP, How would one send a large array >> MTU ?  Does it still need 
> to be broken up into chunks?  

Not by you.
You deal with data that makes sense to you.  The data will be broken
into packets by the network stack.

> And the chunk size would be...?  

What ever you devise in terms of handling data on both sides.  Your
chunk size is constrained by your application, memory, and those kinds
of issues.

> (In UDP a chunk is limited to a number slightly less than 2**16)
> 
> When would I consider using sendall?
> 
I think you would normally use sendall.

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

TCP allows you to deal with streams of data - much like files.   UDP
allows you to deal with packets of data - ideal for quick messages over
the network.

> 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? or that 
> it 'guarantees' delivery.  When does it give up?

Sorry I could not make the meeting.  We have
http://www.librarything.com/catalog.php?view=dlslug&searchall=1&deepsearch=foundations&shelf=list
Foundations of Python Network Programming in the library

It covers these issues quite nicely with useful example code.

> 
> As I understand it, in tcp the client has to create and destroy a 
> socket(s) for each transaction.
> 
> How does the client know if all the data is sent?
> How does the server know it got everything?

Have the server send a confirmation.  How were you doing this with UDP?
You can use the same approach, but the chunk size can be something that
makes sense for you as opposed to being dictated by the packet size.

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

Yes.  Data will get buffered until a request finally pulls it out of the
socket.  You can saturate the buffers and create a deadlock.  The book
includes a cute deadlock example (pp 61-62) where buffers get saturated.

> As seen by the example below:
> ----------------------------------------------------------------
> client sends data for FFT.
>                                                         Server starts FFT.
>                                                         Server sends I'm 
> busy
> client receives I'm busy
>                                                         Server sends 
> results
> client receives results

This approach makes more sense to me than the following one.  Your
client knows that the data was sent successfully and that the FFT is
underway.  You can have timeouts for both the data transmission and the
FFT processing in the client.

> ----------------------------------------------------------------
> Or should it be more like:
> ----------------------------------------------------------------
> client sends data for FFT
>                                                         Server starts FFT.
>                                                         no response from 
> server
>                                                         Server sends 
> results
> client receives results
> ----------------------------------------------------------------
> 
> Can you tell I've never done this kind of thing before :)
> 
> -Bruce
> 
> OK, I'm going back to my copy of Beej's Guide to Network Programming, 
> where I'll find some answers, and a bit of confusion too...
> 
> 
> ******************************
> Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail.  Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
> ******************************
> _______________________________________________
> Python-talk mailing list
> Python-talk at dlslug.org
> http://dlslug.org/mailman/listinfo/python-talk
-- 
Lloyd Kvam
Venix Corp.
1 Court Street, Suite 378
Lebanon, NH 03766-1358

voice:  603-653-8139
fax:    320-210-3409