Since you haven't provided all of the code that you are using I have to try and make an educated guess:

First most likely cause of your hang is that you aren't actually writing a newline to your socket, and so READ-LINE on the other end will hang indefintely. Don't use PRINT when you care about the formatting of the output (unless you REALLY know what you're doing). You should use something like:

Second most likely cause is that you are writing bytes on one end of the stream, and characters at the other. Depending on your implementation and choice of EXTERNAL-FORMAT for the socket this may not work as you might hope. FLEXI-STREAMS from quicklisp can help you if that is indeed the problem.

If it's neither of those then I don't know what else to suggest without your full code to play with.

As an aside, writing a file to a socket one byte at a time is AWFUL, you should be using READ-SEQUENCE and WRITE-SEQUENCE.

First most likely cause of your hang is that you aren't actually writing a newline to your socket, and so READ-LINE on the other end will hang indefintely. Don't use PRINT when you care about the formatting of the output (unless you REALLY know what you're doing)

i tried that, but without success

Second most likely cause is that you are writing bytes on one end of the stream, and characters at the other. Depending on your implementation and choice of EXTERNAL-FORMAT for the socket this may not work as you might hope. FLEXI-STREAMS from quicklisp can help you if that is indeed the problem.

I played around with that a little bit and that doesn't seem to be the problem either.

one thing that i noticed though, is that the file is only received completly when/after the stream is closed. why is that?

David Mullen wrote:Is there a difference between force-output and finish-output with this API?

That's a good question that I don't know the answer to.

But I kinda figured out what the original problem was and everything works now.read-byte just keeps waiting for input when the stream is empty. So when all the bytes of the file are read it just hangs there.I changed the code as follows and it works now:

David Mullen wrote:Is there a difference between force-output and finish-output with this API?

That's a good question that I don't know the answer to.

Looking at the SBCL sockets code, the documentation on sb-bsd-sockets:socket-make-stream notes: "Acceptable values for BUFFERING are :FULL, :LINE and :NONE, default is :FULL, i.e. output is buffered till it is explicitly flushed using CLOSE or FINISH-OUTPUT. (FORCE-OUTPUT forces some output to be flushed: to ensure all buffered output is flushed use FINISH-OUTPUT.)"

Kuro wrote:But I kinda figured out what the original problem was and everything works now.

Yeah, it makes sense that this works. It just seems conceptually hairy to use LISTEN in a bivalent way, when the standard implies it's a character-oriented operation. Like, I wrote this:

Here, the element being listening for will depend (strictly speaking) on both the type of the sequence and the format of the stream. In the case of multi-byte character encodings, the input element could be a byte or a character-code sequence—so it would make sense to specify which. And this is what Allegro CL does: LISTEN takes an optional argument to know what to listen for—either a character or an octet. An old post on comp.lang.lisp touches on this:

Duane Rettig wrote:Most fundamentally, CL was developed (note I did not say standardized) at a time before internationalization was popular, when "characters" were the fundamental building block, and bytes were still potentially variable. The description of cl:listen implies this. The time line is of course slushy, and there are those that will argue (incorrectly) that the byte has always been 8 bits, or that characters have always been un-tied to the octet (8-bit-byte). But though this certainly has been true in some pockets of locality, it has only been recent (perhaps the last 10 to 20 years) that the tide has turned toward the proliferation of this reversal, where the octet (8-bit-byte) has become the fundamental data unit of transfer, and the character has achieved some variability.

Come to think of it, the more concrete pitfall here is latency—where LISTEN will return false if (some of) the data hasn't arrived yet. In that event, you'd miss out on the rest of the file. (Not a problem with localhost, I guess.)