[email protected]
[Top] [All Lists]

Re: Is there a standard for sending and receiving between applications u

Subject: Re: Is there a standard for sending and receiving between applications using sockets?
From: "$Bill Luebkert"
Date: 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:[email protected]
 (_/   /  )    // //       DBE Collectibles    Mailto:[email protected]
  / ) /--<  o // //      Castle of Medieval Myth & Magic http://www.todbe.com/
-/-' /___/_<_</_</_    http://dbecoll.tripod.com/ (My Perl/Lakers stuff)
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

<Prev in Thread] Current Thread [Next in Thread>