How to end TCP socket data while using readline()?

[Arjun Chennu]

Thanks for the feedback.

Opening a separate file-obj for writing and for reading is just what I've
been trying, but I don't seem to get it to work. I'm new to python and I'm
not sure if I'm missing the intricacy of some command. Please help:

Here is my server snippet:

            (conn, addr) = sock1.accept()    # connected socket
            print 'Client (localhost) port: ', addr[1]

            cf = conn.makefile('r',0)    # file obj for reading
            lf = open('ccs.txt','w')

            for linenum, line in enumerate(cf):    # iterate over socket
lines
                lf.write(line)
                #sys.stdout.write(line)
                print len(line)

            cf.close()

            stat = 'wrote %s lines to file.\n' %(linenum+1)
            cff = conn.makefile('w',0)   # file obj for writing
            cff.writelines(stat)      # cff.write(stat) does not work
either!!
            cff.close()

            lf.close()
            conn.close()
            print stat, "DONE!"

And here is the client that I have for it:  (sfp is the local file object i
read from)

        for line in sfp.readlines():
            cf.write(line)
            print len(line)

        print 'done sending'
        cf.close()   #writing ends here

        cff = s.makefile('r',0)   # file obj for writing
        for line in cff.readlines():
            print line

        cff.close()

        sfp.close()
        s.close()

The execution sends all the lines (and prints out the len(line) ) and then
stays waiting. THen when I manually terminate the client script, the server
script happily types the "DONE!" output.

Where is this protocol hanging up? Help much appreciated, with a small
explanation.

Cheers,
Arjun

On Sat, Feb 27, 2010 at 05:11, Cameron Simpson <cs at zip.com.au> wrote:

> On 26Feb2010 10:39, Arjun <arjun.chennu at gmail.com> wrote:
> | Hi, I have a small script that runs a TCP server. A client connects to
> | this server and transmits a stored file line-by-line, and then waits
> | for a confirmation "done". However, when I run them the first loop
> | never really ends -- as the TCP server keeps expecting more data. I am
> | using a file-like-object, and so somehow I have to communicate to the
> | server that it is the end-of-file.
> |
> | here is some server code
> | <snip>
> |             sock1.bind(('', port))
> |             print "Listening at port: ", port
> |             sock1.listen(1)      # listening socket
> |             (conn, addr) = sock1.accept()    # connected socket
> |             print 'Client (localhost) port: ', addr[1]
> |
> |             cf = conn.makefile('r',0)    # file like obj for socket
> [...]
> |         print 'close'
> |         cf.flush()
> |         cf.close()
> |         sfp.close()
> [...]
>
> Too many files. It's not that hard! Or shouldn't be.
>
> | So what I am wondering is:
> |
> | 1. Using a file-like object means that the socket becomes uni-
> | directional, until the mode of the file object is changed from 'r' to
> | 'w' (or vice versa). This seems inefficient, and rather unPythonesque.
> | Can somebody tell me if there is a more elegant way of receiving all
> | the lines from the client, and then sending a "done" message to the
> | client?
>
> Get the socket. It is a file descriptor (or in may be a python "socket"
> object with a file descriptor inside).
>
> Open _two_ "file" objects on it using
>  from_file = os.fdopen(fd_of_socket, "r")
>  to_file = os.fdopen(fd_of_socket, "w").
>
> Use the same:
>  print >>to_file, 'close'
>  to_file.flush()
> method as you're using already.
> Read from to_file as needed.
>
> The same scheme should work in both server and client:
>
> Don't look for EOF, watch the input line flow.
>
> You might need to use readline() instead of the file-by-line iteration
> stuff,
> which I seem to recall has some sort of problem handing out the "latest"
> line.
>
> Cheers,
> --
> Cameron Simpson <cs at zip.com.au> DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
> It's better, when you're riding with someone you don't know so well, to
> stick
> to the inside line - it's easier to avoid the bits...
>        - Barry Sheene
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100301/302c1427/attachment.html>