Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Interplatform (interprocess, interlanguage) communication Date: Wed, 8 Feb 2012 01:31:24 +0000 (UTC) Organization: UK Free Software Network Lines: 28 Message-ID: References: NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1328664684 29350 84.45.235.129 (8 Feb 2012 01:31:24 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Wed, 8 Feb 2012 01:31:24 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11839 On Tue, 07 Feb 2012 16:38:31 -0700, BGB wrote: > in general, I agree (sockets generally make the most sense), although > there are cases where file-based communications can make sense, although > probably not in the form as described in the OP. > Yes, for small amounts of data or message passing between processes I tend to like sockets - as others have said, the fact that they are agnostic about the location of the communicating processes is often very useful. > usually, for passing messages over sockets, I have used "compact" > specialized binary formats, > Yep. ASN.1 has to be about the most compact way of encoding structured, multi-field messages with XML occupying the other end of the scale. That said, for short, list of fields messages I often use a CSV string preceded by an unsigned binary byte value containing the string length: this type of message is both easy to transfer, even if the connection wants to fragment it during transmission, and by having a printable text payload, its also convenient for trouble shooting. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |