[Python-talk] A few more socket related questions

[Larry Keber]

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.
>
>   

I didn't make it to the meeting after all.  I wish I had; sounds like it 
was an interesting time.

> Using TCP, How would one send a large array >> MTU ?  Does it still need 
> to be broken up into chunks?  And the chunk size would be...?  (In UDP a 
> chunk is limited to a number slightly less than 2**16)
>
> When would I consider using sendall?
>   

sendall() will attempt to send your entire piece of data, and cause am 
exception if there's a problem (which should be unlikely if you're on a 
LAN and have no cable/hardware problems anyway...)   I've used it to 
send large chunks of data as part of a network bandwidth testing tool I 
wrote a while back.

... Hmm, looking at my old code, actually I used send(), not sendall().  
I don'nt remember why, or whether there was any good reason for choosing 
one technique over the other.

Yesterday I sent a reply suggesting netcat as a possible way top avoid 
having to do socket programming on the server side:

> Maybe you could use netcat to handle the socket stuff on the server 
> side? (I don't know what the environment is there, but if python is 
> available, I'm sure netcat is available, or you can get and compile it).
> http://en.wikipedia.org/wiki/Netcat
>
> Have it wait for a connection, then run your program (with netcat 
> linking the socket input to your C program's stdin) similar to:
>
> nc -l -p 1234 -e /bin/bash
>
>
> substituting your program for /bin/bash. 

I'm not 100% sure my mail made it to the list, though.


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

It's good for when you just want to send a stream of data to the other 
side, and don't want to manually handle retransmissions and acknowledgments.

>  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?
>
>   

I don't remember the answers to that.  My network programming books are 
at home...

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

Not really, you could create one and keep it open as long as you want.

> How does the client know if all the data is sent?
>   

With TCP, as long as you sent it all and there was no exception, it got 
there.

> How does the server know it got everything?
>   

If you know ahead of time the size of the data you're expecting, you 
should have gotten at least that many bytes.  Or, you could have some 
sort of protocol where the clients sends the size of the data set as 
part of the transaction.


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

I think either of your examples below would work.  You can use the same 
socket for C->S and S->C communications.

Larry

> 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
> ----------------------------------------------------------------
> 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
>