emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [feature request] SOCK_SEQPACKET


From: Daniel Hackney
Subject: Re: [feature request] SOCK_SEQPACKET
Date: Thu, 3 Dec 2009 16:23:32 -0500

Stefan Monnier <address@hidden> wrote:
>> At any rate, it looks like supporting SOCK_SEQPACKET over AF_UNIX
>> wouldn't be that bad (I've basically got it working), so it might be
>> worth cleaning that up for inclusion and waiting to see if anyone
>> with the proper knowledge wants to come along and add SCTP support to
>> Emacs.
>
> Emacs hasn't been at the forefront of the networking technology, and I
> don't see why that should change, so SEQPACKET with AF_UNIX is
> perfectly sufficient.

Well, from an "I want ponies" perspective, it would be great if Emacs
supported every network type :)

> If/when someone needs SEQPACKET over AF_INET, we may then consider
> whether and how to add support for it.

Plus, it looks like there are issues with underlying OS support, so it's
out of our hands for now.

>> By the way, there were a few changes that needed to be made in order
>> to allow creating AF_UNIX SOCK_SEQPACKET servers, basically replacing
>> "socktype == SOCK_STREAM" with "socktype == SOCK_STREAM || socktype
>> == SOCK_SEQPACKET". I've attached a patch (to be applied after Stefan
>> Monnier's previous patch) which takes care of this.
>
> That's all?  With my patch plus yours, it works?

Yup. I have cookies flowing brilliantly between Emacs and Uzbl, and
simple scripts connect just like they should.

> The mind boggles (I never wrote any networking code, so my patch was
> really just an "educated guess" based on the existing code and the
> manpage).

Same here. The nice thing is that it seems like SOCK_SEQPACKET can be
used basically the same as SOCK_STREAM, but with some additional funky
stuff (as well as using SCTP when done of AF_INET).

The only thing to consider now would be to try to take advantage of
SOCK_SEQPACKET's record delimiters, which are exposed through recvmsg(2)
and sendmsg(2) and the struct msghdr. This would allow for record
delimiting at the socket layer, potentially making certain kinds of
operations easier.

Without having looked at it, it seems like emacsclient could benefit
from record delimiters, as each command sent over the socket could be
delimited by a MSG_EOR, reducing the need for dealing with delimiting
records at the application layer.

I'll start to take a look at this, but it may be more effort than it's
worth, because of the limited AF support for SOCK_SEQPACKET. It looks
like, at a minimum, we would have to replace the calls to emacs_read/write()
with sendmsg()/recvmsg(). Also we would need to think about how to deal
with MSG_EOR in the context of reading into a buffer. There isn't any
change to the stream, but certain calls to recvmsg(2) would include a
MSG_EOR with them. Off the top of my head, it seems like we could call
the process sentinel when MSG_EOR is encountered.

Looking at the info page for sentinels, it looks like there could be a
chance that the sentinel might miss two MSG_EORs if they are encountered
in quick succession, though I could be wrong about this.

Anyway, I'm mainly thinking out loud here, let me know if I'm entirely
crazy :)

--
Daniel M. Hackney




reply via email to

[Prev in Thread] Current Thread [Next in Thread]