Re: Is there a standard for sending and receiving between applications u
Re: Is there a standard for sending and receiving between applications using sockets?
Sat, 11 Dec 2004 22:34:53 -0800
John V. Pataki wrote:
> -- I understand that from the socket's standpoint it is all coming in stream
> - and I want to know how to handle each glob of info...
> -- Can you explain buffered and what is really happening when you 'turn it
> off' or 'turn it on' or 'autoflush' etc....
Buffering just means the the IO subsystem holds data until a buffer is
filled before outputting it - thus saving on IO cycles. You can defeat
that by turning buffering off which forces the data out on each write/print.
Sometimes a newline is needed to properly force a line of data out (probably
only in text mode, but not sure exactly when/why). the autoflush method
on a socket will turn buffering off/on.
>>Also - how can tell when the data stream is over for the current message?
>>Is there a built in EOF-like check I can make?
EOF occurs when the remote sender closes the socket.
> -- This is what I was actually thinking of doing .. Just want to see if
> there was already a standard out there for doing this instead of
> re-inventing the wheel....
I'm not sure there is anything you could call a standard. You could use
UDP rather than TCP since it is record oriented, but buffer size would
be limited (not sure of the max size - could be 8800 [RPC], possibly more).
> -- Doesn't the following take care of this:
> my(@ready) = $sel->can_read(0);
> return if $#ready == -1;
That will block your task till data is available - conceivably forever
if something went wrong. You also have to check the read to make sure
you don't read after again without doing another can_read.
> Or does can_read(0) mean that the $sel was readable at one time?
It means that the system has input data buffered.
> -- Hmmm.. I will look into this... Is UDP just as fast and reliable as
Probably just as fast, but it's not connection based and doesn't guarantee
> -- what would the advantage be of sending binary - faster ?
Imagine sending a GIF. You don't have to uu/base64 encode it if you
are transmitting binary (less data to send).
,-/- __ _ _ $Bill Luebkert Mailto:dbecoll@xxxxxxxxxxxx
(_/ / ) // // DBE Collectibles Mailto:dbe@xxxxxxxxx
/ ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/
-/-' /___/_<_</_</_ http://dbecoll.tripod.com/ (My Perl/Lakers stuff)
ActivePerl mailing list
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs