I would URGE you to make this exclusively a Boost.ASIO implementation.
I like this idea. I wasn't sure it was appropriate though and frankly, from having poked through the source a bit, ASIO is a bit intimidating in the way it's structured. But I'm sure that's mostly a lack of familiarity with it and only vaguely understanding the core principles which can surely be remedied by some study of the documentation.
3. There seemed to be some confusion regarding named pipes on POSIX. The only difference between Windows and POSIX named pipes is that the former use the NT kernel namespace, within which the filing systems are mount points, whereas the latter use the filing system namespace directly. In my own code, I use a magic directory in /tmp as the namespace for all my named pipes in the system in an attempt to replicate a similar behavior to Windows, but there are many other ways of doing the same thing.
Hmmm, I see what you're saying and I agree with it, but I'm also not sure
I hear you on ASIO's intimidation! (https://ci.nedprod.com/view/All/job/Boost.AFIO%20Build%20Documentation/Boos t.AFIO_Documentation/doc/html/afio/introduction.html) Due to a failure of its maintainer to timely address the bug https://svn.boost.org/trac/boost/ticket/8669 (with possible dupes https://svn.boost.org/trac/boost/ticket/8933 and https://svn.boost.org/trac/boost/ticket/8935), I ended up having to reimplement a bug free alternative version which actually was quite painless to do once you figure out how ASIO works. The hard part was definitely trawling the source code to figure out why and how, but once you reach understanding it's all fairly obvious. BTW you should read the comments at https://svn.boost.org/trac/boost/ticket/8933 as they mention an existing named pipe implementation for Windows ASIO. Contacting the author might save you some time. that
it's strictly true that this is the "only" difference.
Correct, I meant "only semantic difference".
Also, to clarify when you say POSIX named pipes, you are talking about the mkfifo call, correct?
I'm talking about any pipe which can be uniquely identified within the system by some string identifier.
And is there a reason why the mkfifo call is more desirable to use than UNIX domain sockets?
Also, FYI, I'm doing this project as an independent study through my CS
Only consistency with Windows. Windows' pipes do offer message datagram semantics like unix domain sockets, so one could duplicate semantics there too. In my own personal code though I have never found the need. program.
I'm getting close to the end of the quarter and I need to have something concrete to show for my efforts. Since I've already started down the path of implementing this not inside of Boost.ASIO, for the purposes of my school project I'm going to continue with that. However, I plan to continue working on it after the scholastic bit is finished, and then I would be interested in implementing it as part of ASIO.
Sure, no problem. I would still believe though that you'll write far less code and it will be less effort to debug if it's exclusively ASIO. On that basis, I would even say it's worth chalking up your existing implementation as a learning experience and starting again. That said, if your compsci department was like mine back in the day, they give better grades to longer code which doesn't test the domain knowledge of the grader. An ASIO implementation would be too short and too domain knowledge specific for good grades I think. It's one of the reasons I got an average 32% during my Software Engineering degree. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.