DenYoNet received

It would still be nice though if there was a possibility to read out that flag somehow, i couldnt find anything about the flag in the W5100 datasheet.
I think that you are highly confused here. Let me explain a bit about the PUSH flag.

TCP data sent to a TCP connection is not actually sent to the net immediately. Instead, the TCP/IP stack (any poperly made stack) will wait for a few milliseconds in case the application has more data to be sent. This allows the stack to send packets with the maximum possible size, which is good for data throughput. For example, if you issue three consecutive TCP send commands of 100 bytes each, the stack will actually send one single packet with all the 300 bytes. Data is sent when a full packet can be sent (usually about 512 bytes of data) or after a short timeout.

The PUSH flag is used to override this behavior. When you send data with this flag set, you are telling the TCP/IP stack "send this data immediately, do not wait for further data". This is useful for example for interactive telnet connections, in which the user expects immediate feedback after sending a few keystrokes (perhaps just one).

So, if you could retrieve the PUSH flag of the received TCP data (the W5100 will not allow you that, indeed, but anyway this is not supported by the TCP/IP UNAPI specification either) this would tell you that the sender wanted you to receive this data as quickly as possible. That's all. It has nothing to do with flow control; other TCP/IP stacks could send TCP data with the PUSH flag set always, sometimes, or never. The fact that you are receiving PUSHed data at the end of the data is purely a coincidence.

Note also that TCP is a pure stream-based protocol: there is no concept of data structures nor any way to know when the data starts or ends. This must be handled by a higher level protocol (for example using a special mark to signal the end of the data, as you did).

I just add the text FILDONE at the end of the data and check it while recieving
Why don't you just send the data size in advance? That's a much neater approach, and is the one used by other existing higher level protocols, such as HTTP.

Is there any way to increase the buffer size? There seems to be a 16KB segment on the chip while only 2KB is used for rcv buffer and 1KB for the send buffer. As far as i counted less then 512 bytes is used for variabeles while 4KB is reserved for it.
Not without breaking the TCP/IP UNAPI BIOS. The W5100 allows only four sizes for the transmit and receive buffers: 1K, 2K, 4K and 8K. It is true that only about 500 bytes are used for variables, but if I assign 2K for the transmit buffer of each connection I run out of memory for these variables, so the only option is to assign 1K.

I didnt mean the transmit buffer, only the receive buffer, as it might speed up the recieving of data.
The receive buffer could grown from 2K to 4K, but then there would be just two available connections (including UDP). Anyway I'm not sure that this would imply any change on the receiving speed; the speed of the whole process is likely to be limited by the processing speed of the MSX itself.

Im gonna check out what the fastest way is to send files, sending file size in advance is ok but also an "end of file" option will work.
You seem to be somewhat obsessed with speed The end of file mark option is somewhat dangerous: what if some of the files you send happen to have the end of file mark as regular content? Anyway, there are protocols that use this technique, such as MIME; but the chosen terminator is quite long and has always a random part.

I havent checked the tcp defenition much as the chip handles most anyways
Sure, the TCP/IP stack handles the low level details; but you still need some basic knowledge about how the TCP protocol works. You need at least understand that it is a stream based protocol, with guaranteed ordered and uncorrupted data delivery but without any guarantee of delivery speed; that connections have always one of a possible set of states, some of which allow sending data and some don't; and that each side of the connection can close it sepparately (the other side can keep the connection open and still sending data).

As far i know Mget dont need internestor, it need the memory helper.

I really hope konamiman will fix the PING.COM error, not being able to return to DOS when pressing any key.......

For FTP server on PC you can use:
http://filezilla-project.org/download.php?type=server