[Gambas-user] Socket Limitations

[Doriano Blengino]

Kadaitcha Man ha scritto:
> 2010/1/4 Doriano Blengino <doriano.blengino at ...1909...>:
>> I think that there is
>> something extreme in trying to send large chunks of data in  a single
>> instruction,
>>     
>
> Weeeelllllll... Not necessarily. If the document is imprecise, which
> it most definitely is, it is fair to make assumptions then complain
> loudly to the developers when you find out that your assumptions are
> wrong.
>
> As for actually addressing your point, perhaps you are right, it may
> be extreme, but as it stands, gb3 does not allow for sending "large
> chunks of data in a single instruction" unless blocking is on. The
> whole point of what I was saying earlier is that gb3 has no mechanism
> for managing the transfer of such large blocks without blocking.
>   
This is a contradiction. Blocking mode serves the purpose of simplicity 
- if you want to send 700Mb in a single instruction, well, you can do 
it. But you can not send 700Mb *and* want to be non-blocked! Look at this:

    write #1, my_700_mb_block
    if error then...

In blocking mode all is fine: the first instruction takes several 
minutes, and then terminates either with error or by having completed 
the job. The second instruction takes the appropriate actions. But if 
the first statement is non-blocking, the second instruction can not test 
for success or not - you should test at later time, perhaps several 
hours later. So non-blocking mode raises event to notify about what 
happened in background.

In reality, it could work the way you say. The first statement starts 
the writing in background; the second tests for previous errors, and 
perhaps for some problem occurred early in the first statement. When 
closing the channel, all the errors are gathered together. This is the 
way the kernel uses, even for normal files - asynchronous I/O. But... 
again, the close() would be blocking! If in a rapid succession you open, 
write a lot, and close, there is no way to obtain an error result. 
Unless you are prepared for a very late notification... what about if in 
the meantime the object meant to receive the notification does not exist 
anymore? :-)... Things are getting complicated...
> I am communicating with RFC 3977 compliant servers and there is no
> defined limit on file size in RFC 3977. What limits the size of a
> single data transfer is the reliability of the connection between the
> server and the client. That puts the onus on me to test various
> configurations and to arrive at a file size that can be reliably
> transferred. FWIW, I would not go beyond 512k, even with today's
> technology.
>
>   
No, no... I was saying that I find it "extreme" to send large chunk of 
data in single instructions, but by no mean I would intend that this 
should be forbidden or wrong. Anyway, data sizes are growing all the 
time: ram in computers, HDUs capacity, file sizes, DVDs (Blueray?) and 
so on. I thought so because in your example there were 48K (do I 
remember well?) to send, and I asked myself if those 48K could ever turn 
to 480K, which could be even more "extreme"...

Ok, I have "sproloquied" (piggy italian-latin-english term for 
"overtalking") enough.

Best regards, and happy big-chunks-stuffing-in-hyperspace.

Doriano