max bytes we can send by send()

[dev]

hello all,

what is the limit/upper range on number of bytes that we can send using send()? and what bout write(), what r the relative advantages and disadvantages between two?



dev

[RobSeace]

Well, send() and write() both take a "size_t" for the length, so the
theoretical max would be whatever the max value a size_t can take
on your system... (Typically, size_t is an unsigned long int... So,
whatever ULONG_MAX is on your system... 4G on a 32-bit system...)

As for the relative advantages/differences between send() and write()...
Well, I normally like write() because it's simple, and works with normal
file-based I/O, too... But, I've heard it doesn't work with sockets on
Windoze, and perhaps other similarly brain-dead non-Unix OSs... Not
that I really care about that... ;-) But, send() has optional special
behavior which you can specify via its flags argument, too... That's
something you can't do with write()... (Though, I honestly rarely have
need to ever use any of send()'s flags for anything... On occassion, I
might want to use recv() over read() so I can use MSG_PEEK, but I
don't think I've ever had a similar need to use send() over write()...)

[emihaly]

Hey rob! Too much information, simple:

you can send with "send" command size of free send buffer of socket.
Its all

[RobSeace]

Are you implying I'm turning into Michael???? ;-) (I don't know... The
last time I looked, I think I DID have more posts than him, which is
kinda scary... ;-))

But, I don't think your answer is really accurate... Yes, the socket
send buffer size will limit how much can be atomically written in a
single chunk... However, with blocking I/O send()/write() MIGHT
block if you specify more, and then write the rest when space
clears up... (Or, it might return a short write, which is why you
need to wrap your I/O calls... There's no real way of knowing for
sure what will happen, unless you know the specific system you're
working with... Either are valid behaviors, though, I believe...)
I still stand by the theoretical max being the max a size_t can hold...
But, then, how often does anyone need to send 4G in one shot,
anyway?? ;-)

[emihaly]

somwhere, sometime was some line of code how to detect how much free bytes is aviable in send buffer. Now i need it, but i cant found it :(o)

[RobSeace]

You can do that via the TIOCOUTQ ioctl()... (Or, SIOCOUTQ, if your
system defines that...)

[sangfroid]

I still couldnt get the main difference between send,write ... Will u please shed some more light on this ?

and how about writeln?

[RobSeace]

What the hell is "writeln"? Are you talking some non-C language, here?

I'm not sure how much clearer I can define the difference between write() and
send(), than I did above... send() works on sockets only, and is more portable (if
you care about non-Unix-like OS's), and allows you to specify flags for optional
behavior, which may be useful in some cases... write() works on any file descriptor
(which includes sockets, on Unix-like OS's), and is effectively equivalent to doing a
send() with a zero flags value... What else do you want to know about them??

(On a side note: I think some of my old comments above are slightly wrong, too...
While the theoretical max for a size_t would indeed be 4G on a 32-bit system, I
think you'd find the real upper limit is going to have to be 2G, since the return value
from write()/send() is a SIGNED int...)