[Python-talk] A few more socket related questions

[bruce.labitt at autoliv.com]

Lloyd Kvam <lkvam at venix.com> wrote on 08/28/2009 02:56:08 PM:


> > > You deal with data that makes sense to you.  The data will be broken
> > > into packets by the network stack.
> > > 
> 
> You could devise a simple protocol where you:
>       * send the count of numbers.
>       * send the numbers (160MB or whatever matches the count).  You can
>         send as a huge block or in smaller blocks as you pull from the
>         generator.  (Though I've never actually sent a block of more
>         than a few MB, I would expect it to work.)

                The generator output is 160MB :)  each time :)
>       * recv delivery confirmation
>       * recv results
> 
> That allows for testing with small chunks of data. 

Believe me, I wouldn't try the whole enchilada at once!

> TCP will deliver the
> 160MB or die trying.  You catch the exception or timeout waiting for
> confirmation.  You can also timeout on the recv results processing.
> > > 
 
> > I was, and am still a little unclear on how to construct the 
> > communications.  Would something like this be reasonable?
> 
> Yes.  Keep responses short.  Use a finite state machine unless your
> protocol is trivial
> > 
> > For every client command, 
> > 1. client requests a socket to server.  thru magic this happens
> > 2. client sends command to server.
> 
> So far, the only command appears to be
>         process nnnnnnnnnnnn numbers
>         <stream of nnnnnn numbers>
> 

I hadn't looked at it that way.  Could be useful...

> > 3. the server must respond with an acknowlege message.  The 
acknowledge 
> > message can contain 'BUSY','ACK', or 'ACK'+data.  'ACK'+data shall be 
sent 
> > if the data is available.
> 
> The server could simply send('ACK') for the process command and start
> processing the number stream.
> 
> Then send 
>    result <length>
>    <result stream>
> > 4. if the command requires it, auxilliary data will be sent by the 
server 
> > to the client
> 
> You should include a length specifier in your protocol (you may have
> been doing that implicitly) since you're constructing a protocol.  The
> simpler case is too simply assume you have the whole transmission when
> recv returns no data.  Essentially that is the netcat approach.
> 
> > 5. on receipt of the acknowledgement (or ack + data) the client closes 
the 
> > connection
> 
> Right, close the connection after getting your results.
> 
> > 
> 
> You could also consider using Larry's netcat (nc) suggestion.
> 

I looked at netcat after Larry mentioned it.  If I understand correctly, 
netcat will do a file transfer, but not a RAM machine 1 to RAM machine 2 
transfer.  Or, I don't understand the tool, nor how to use it yet.


> > 
> > -Bruce


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