SSHDOS linux modification GET problem

Hi!, I´m working with sshdos to make an sftp linux client.

The client connects, list and put files without problem.
But with "get" happends something strange.
With files that have small size (less than 1 K or less), no problem; but when I try to get any file with more size, the applicattion says; Socket read error on trasprt.c At this point:

if (n = read(GlobalConfig.s,inbuf+16,PktLength-16) != PktLength - 16)

But only fails if the filesize is greater than 1kb moreless.

Anybody knows what happens?? Why this socket reading fails only for this files?

Sorry my poor english, thanks

PD: Also fails listing files if before puts a file (greater than 1kb).

Well the socket code is broken, in that it assumes that the buffer will be filled every time.

This is simply not the case for network TCP traffic, as messages can be fragmented on transmission and delivery.

I don´t understand your reply.
This program runs with paquets, this line read the rest of packet (before I have read the header with if ((n = read(GlobalConfig.s,PktInLength,16)) != 16)

And all the process of authentification, listing,put,get.... runs with packets and runs ok.
Only fails with long packets with get. (with put don´t worry sizes).
The code is so large to post here, but if was necesary I post it.

http://www.cs.ucla.edu/classes/fall0...s/distcomp.pdf
In particular, Slide 18

If you send 10 bytes followed by another 10 bytes, then it is pure LUCK if you receive 10 bytes and 10 bytes.

What is more usual, especially when you start to bump up the data volumes is that messages become fragmented.

So sending 10 + 10 might be received as 7 + 9 + 4. It's still a total of 20 in and 20 out, but it's YOUR job to reassemble the data into meaningful packets of data.

By the same token, asking to send 10 bytes might only result in part of the data being sent, in which case you need to retry with the remainder.

TCP is a stream protocol, which means you're guaranteed to get the bytes out the same order that you put them in - nothing more. Fragmentation at both ends is something you have to take into account.

UDP is different, either you get the whole message in its entirety, or you get nothing. That is, it is an unreliable connection. Also, UDP packets can arrive out of order.