"BAZLEY, Sebastian" <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>>
>> In article <FB30E6123B22D211B52800A0C9CFBB19010C0E9F@LONES2>,
>> "BAZLEY, Sebastian" <[EMAIL PROTECTED]> writes:
>> > On VMS, syswrite() returns undef if one tries to write more
>> than 65535 bytes
>> > on a socket.
...
>> For example in Perl if you do a print to a mailbox:
>>
>> print MBX "blah blah\n";
>>
>> The "\n" is stripped (by the CRTL) before writing to the mailbox. If
>> you read from a mailbox, a "\n" is tacked on the end of the record by
>> the CRTL before Perl gets the data.
>
> Yes, but writes to mailboxes are surely unlikely to be more than 65535 bytes
> long, surely?
The point was that mailboxes (like sockets) are non-file-structured devices
and that they *may* get much the same treatment by the CRTL.
This is especially so because the "default" sockets i/o in Perl is just to
do "read" and "write". So writing to a socket or to STDOUT (when STDOUT
is a mailbox) will go through the same code in Perl.
There are some preprocessor flags (PERL_SOCK_SYSWRITE_IS_SEND, etc.)
to require "read" from a socket use a "recv" call, and "write" to a
socket use "send"....if network i/o is going to get special treatment,
we may want to define those flags so that normal i/o isn't affected by
fixups you're doing.
>>
>> My *bet* is that you want to break at \n bytes, but you'll have to try
>> it and see.
>
> I came across the problem when trying to use FTP via LWP to upload a Zip
> file. Forcing the max chunk size to 65535 (in Net::FTP::I) fixed the
> problem.
That's a good sign!
> But when I contacted the Net::FTP author, he not unreasonably suggested that
> syswrite() ought to write as much as it can, and return the length of what
> it has written. Hence my original posting ... apologies for not making this
> clear originally.
Well, the *real* problem is in the CRTL, but we'll just have to work
around it.
It might be worth trying with "send" instead of "write"...as I
mentioned in a post a few days back, I saw an unexpected difference
between "recv" and "read". Perhaps "send" does the right thing with
large records where "write" doesn't.
If "send" doesn't help, then by all means truncate writes to sockets
in PP_SYS.
> If the code can be fixed so that it only truncates writes that would
> otherwise have failed, then this ought to be an improvement, no?
Yes indeed! And hopefully nothing else will break in the process :)
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
