- Boost - lists.boost.org

Re: [boost] Re: Network library: What we have until now
by Iain Hanson 14 Apr '05

14 Apr '05

On Thu, 2005-04-14 at 11:29 +0400, Maxim Yegorushkin wrote: > On Tue, 12 Apr 2005 21:39:24 -0700 (PDT), Don G <dongryphon(a)yahoo.com> > wrote: > Was not Mac OS Classic been buried long ago? People on this thread are still discussing Win95 :-(. > > IMO, sockets are abstractions out of the scope of any language. Their > interfaces can be implemented using any general purpose programming > language, but still you'll have to call an underlying OS C API. That's a > fact of life and I don't think this is bad - C is the most portable > programming language ever. Yes. But, that is not necessarily the 'C' socket lib :-). An optimal ( but not very portable ) implementation would replace the 'C' socket lib. > Here is my two philosophy cents. > > You propose another set of concepts over socket concepts just to > send/receive a bunch of mere bytes. Geez, another glue layer over sockets > that adds nothing but syntax sugar. Aren't we already tired of software > bloated from glue layers over glue layers over...? You don't just send > bytes, rather you execute protocols. Sockets have the right implementation > level and complexity to build *efficient* protocols upon. I agree with you. I think the well defined concepts developed from BSD sockets and well known by many programmers is what we need for a layer 1 sockets lib. And I've always liked the idea of being able to specify protocols as a Spirit grammar. > Protocol is the > only glue layer you really always need, the layer that binds your > application logic with network transport layer (sockets) providing the [snip] ^^^^^^^^ and Network and Data Link Layers. /ikh

2 1

Re: async socket i/o [long]
by Don G 14 Apr '05

14 Apr '05

Hi Scott, When I implemented this at work, the sync stuff did indeed rely on the internal async mechanism. It turned out "better" not to pass function objects about for the synchronous case, though it would work. So, I guess it is partly a performance thing as well as a convenience thing to allow mixing sync/async without mixing layers. The async flow (aka, "function queue") is something I would like to revisit soon. A key concept of my proposal (which I should post to the sandbox) is cancel. This complicates the use case, but I don't see a way out of it. Best, Don --- Scott Woods wrote: > > Hi Don and Michel, > > > ----- Original Message ----- > From: "Don G" > To: <boost(a)lists.boost.org> > Sent: Thursday, April 14, 2005 4:07 PM > Subject: [boost] Re: async socket i/o [long] > > > > Hi Michel, > > > > > Ok the reason I expose it is for the possibility > > > to write single threaded reactive servers. > > > > I have written such using the library I proposed. The missing > > ingredient is a function queue mechanism. I posted one to the > list a > > couple weeks ago, but feel that it is not technically a > networking > > thing. Of course, the network layer could be coupled to it in > some > > key places which would make things simpler to use. > > > > [snip long useful text] > > I agree and nicely written :-) At least that stuff feels better. I > have to > admit > I'm still tangled up with the broader scope. Wondered if this might > clarify > things; > > [4] boost > --|-------------------serialization-------------------------| > [3] boost --|-----------|---------------|- sync file --|-- sync > socket -| > [2] boost --|-----------|---------------|- async file -|- async > socket -|-------------- > [1] boost --|- sync file -|- sync socket > -|-----------------------------|- > async flow - > [0] system -|- sync file -|- sync socket -|- async file -|- async > socket -|- > async flow - > > Level [0] shows the platform APIs. The repeated names at levels [1] > and [2] > are the > Boost interface to the same names at system level; the boost > versions are > platform > independent. The boost async libraries for file and socket I/O are > bumped up > to > level [2] to highlight the need for a generic "async flow" library. > A means > of passing > control from one dis-joint code fragment to another. > > Sync file and sync socket appear again on level [3] as that > behaviour may be > re-implemented over the async level. > > Serialization is shown at the top for obvious reasons. > > I suppose for any given platform there may be holes, e.g. an old > MacOS may > not > support async file. According to this diagram at least, sync file > and sync > socket are > optionally implementable as either a layer over the platform API or > as > something > that makes use of the boost async file and async socket. > > While this might be all a bit pie-in-the-sky, if sync file and sync > socket > can be > implemented over a platform independent interface, the only time > you wouldnt > do so would be when the platform has no async support? Or for > absolute best > speed as you described in your text? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[hash] Built in arrays
by Daniel James 14 Apr '05

14 Apr '05

I've just checked in an attempt at supporting built-in arrays in boost::hash. It's not great and I might remove it before Friday. My main problem was that overloading hash_value for both T* and T[Size] causes ambiguity - so I implemented it using partial specialization of call_hash. (If anyone knows how to correctly implement the overload, preferably without SFINAE, let me know, although I'll spend some time looking into it if I can find the time). So I implemented it using partial specialization of hash_detail::call_hash. This breaks the specification of boost::hash_combine, which is specified in terms of boost::hash_value - but boost::hash_value is not overloaded for built in arrays. So it might be a good idea to change it so that it's specified in terms of boost::hash. In a way, I prefer this, since users should never really call hash_value directly and I think the documentation should reinforce this. Any thoughts Peter? Daniel

4 14

boost(1.32.0) date_time libraries with stlport4.6.2..single threaded libraries not generated..
by Manish Mangal 14 Apr '05

14 Apr '05

Hi I am trying to create the boost libraries with toolset vc-7_1-stlport. STLPort 4.6.2 has been installed Successfully and runs fine on the system ( VC .Net2003 C++7.1). The problem is that only the multi-threaded libaries are being created. The single threaded (dynamic and static) are not being genereated. I also read on earlier posts a few problems with wchar_t. So I modified the vc71.mak file of STLPort4.6.2 to add /Zc:wchar_t and then recompiled STLPort. I also changed the Vc-7_1-stlport-tools.jam file to look like #feature native-wchar_t : off on ; feature native-wchar_t : on off ; Since the Multi-threaded libraries are being built, I assume I do not have the wchar_t problem. The bjam command I use is: bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_VERSION=4.6.2" "-sSTLPORT_4.6.2_PATH=C:\SourceLibrary\STLport-4.6.2" "-sBUILD=debug release <runtime-link>static/dynamic <threading>single/multi <stlport-iostream>on <native-wchar_t>on" install On one of the boost.regex pages it is written : Note that the full STLPort libraries appear not to support single-thread static builds.... If it is not possible to create single threaded static builds then how to use the boost multi-threaded date_time libraries with the STLport libraries??? Any help is much appreciated. Manish Mangal Stratagen Systems 1-425.821.8454 ext. 136

2 1

Re: [boost] status of circular buffer
by Jan Gaspar 14 Apr '05

14 Apr '05

Hi Vincent, I'm working on it and I'd like the circular buffer to be included in the next version but unfortunatelly I don't have a lot of spare time. You can see the progress in the sand-box cvs. Btw. when is the branching for release scheduled? I can then say yes or no. Jan --- Vincent Torri <Vincent.Torri(a)iecn.u-nancy.fr> wrote: > > Hello, > > I would like to know what is the status of circular > buffer, in particular > if there is a chance that it will be included in the > next version of > boost. > > Thank you > > Vincent Torri > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: [boost] Re: Network library: What we have until now
by Iain Hanson 14 Apr '05

14 Apr '05

On Wed, 2005-04-13 at 20:14 -0700, Don G wrote: > I think this presupposes a mostly manual association of > selectable_object with select_set? The select_set is then used to > wait? Yes. > If not, please explain the importance of "when can non-blocking > operations proceed" vs. "async operations are done". If the > "operation is done" callback occurs by calling dequeuing a > boost::function<> then the app is still "single threaded" to the > user. Not all platforms have threads. There may even be some that don't supply co-operative multi-tasking. Non-blocking calls are akin to polling. A non-blocking read fails if there is no data to read. A non-blocking write fails if there is insufficient space in the queue. If a non-block write succeeds then its behaviour is identical to a blocking write. An async write queues the request and success or failure is reported sometime later. BTW callbacks are just *one* way that async completion can be reported. /ikh

1 0

status of circular buffer
by Vincent Torri 14 Apr '05

14 Apr '05

Hello, I would like to know what is the status of circular buffer, in particular if there is a chance that it will be included in the next version of boost. Thank you Vincent Torri

1 0

Re: Network library: What we have until now
by Don G 14 Apr '05

14 Apr '05

Hi Boris, > I updated > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet > to document why what decisions were made. > We have until now: > * The network library should support four I/O models > which are known to many programmers as blocking, > non-blocking, multiplexing and asynchronous. Personally, I don't think the multiplexing interface is appropriate or necessary. Essentially the same style can be achieved with multi-threaded async and a boos::function queueing solution. In other words, it is not a group of network objects that is being manipulated. It is a portable dispatcher that gets boost::function<>'s queued to it. It therefore suffers none of the portability issues that a direct wrapper to select would have. I also believe that non-blocking is an I/O only thing; it is not needed for connect or accept. > * It should be possible to switch between I/O models at > runtime (which means you have one socket class supporting > all I/O models instead of different socket classes each > of them supporting only one I/O model). Perhaps "switch" isn't the best term. On a per-operation basis, the user should chose between styles. > * There should be an asynchronous I/O library as other > libraries might want to do asynchronous I/O, too. I don't see this as practical. There is no such thing as async I/O that can be portably described. This means that each kind of async object has to provide the right implementation. Perhaps the scope of portability needs to be stated and agreed upon. When I implemented async pipe I/O on Windows NT/9x, I could not use the same code for I/O as I did with sockets or as I would for files (subtle differences). I think a common pattern for async behavior should be agreed upon and if some implementation details turn out to be reusable, that's a good happenstance. My prediction is that on Unix platforms, there will be more to reuse between sockets, pipes, files, etc.. On Windows, there will be little. > * There should be an asynchronous design pattern which > should be used by all Boost libraries which support > asynchronous operations. I agree completely on this one :) > * On a low level the network library should be close to > what is known as Berkeley sockets to many programmers. I think sockets should be hidden. They are not universally used, for example Mac OS9 doesn't and I just assume others exist. They don't have any magical powers; they are just a C abstraction. A C++ abstraction should replace them. > * On a high level there should be I/O streams support. I agree again ;) > As far as I can see from all the discussions that's > what we agree on. There have been some ideas like > event handlers and dispatchers but I am not sure > where to put them - have a look at > http://www.highscore.de/boost/net/packages.png > please (which is also in the Wiki page). This is the > overall architecture of the network library. If you > want me to change or add something please tell me. We have a couple straw men started (Michel's and mine). Perhaps it is just as good to start just throwing darts at them? I could probably have a full implementation of the interfaces I propose in a small number of weeks (2-3). Having done it once before really helps<g>, but I wanted to get to some common ground on the philosophy before going to that step. The philosophy I have on this may be out of sync with some (pun intended), but IMHO, we need to hash over the philosophy as much as anything. We have a lot of folks that are very comfortable with the sockets interface, but I don't believe that exposing its idiosyncrasies is the right approach. Everyone that writes sockets code runs into the same problems, and solves them in varying degrees of sophistication and completeness. A robust solution is not as difficult as some might think. It's certainly easier than getting agreement on philosophical matters. ;) Best regards, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

8 7

Re: async socket i/o [long]
by Don G 14 Apr '05

14 Apr '05

Hi Michel, >Don G wrote: >> I have also been putting together some ideas which are >> similar to those you outlined, though perhaps at a >> higher level of abstraction. I will try to wrap up what >> I have and post it in the next day or two. I will also >> try to look more closely at your code. > > It's not that much code more interfaces ;), but > implementability on at least linux, solaris, windows is > a minimum. I have implemented these interfaces (for my work) on Linx, Solaris, Windows (all versions) and Mac OS/X (and even OS 9, though we have removed that support at this point). The interfaces I am proposing don't mention socket or sockaddr or select et.al.. As a matter of fact, not all OS's even use sockets (MacOS < X doesn't if that matters). I have even implemented these interfaces as a pseudo-network over HTTP tunnels and reflection servers. About the only portability requirements that I can think of are: threads and a network access API of some kind. Not just any network API will do, but just about any system with threads should have the necessary power. There are implementations that would fit only certain platforms that may be better (epoll vs. kqueue vs. select), but a select() based version would be extremely portable for a first version. Subsequent versions could add an epoll implementation and others. I suppose that if multiple choices exist for a given platform, different concrete classes could provide the user with a choice, but see my comments below. I really do believe that the best choice for a given platform should be made (via profiler as necessary) and that should be that. >> From a quick read, it looks similar to the implementation >> path I had used at my work, but probably more flexible in >> how event_dispatcher relates to event_handler. I think >> there is a good likelihood that the two are complementary. > > Ok could you expand a bit? What do you mean by complementary? The code I wrote for work had an implementation-side abstraction with an abstract base like event_handler, though I called it Selectable. It had a signal mask that mapped to your event_handler::event_type_t enum. The thread pool internal to the network object managed calls to select (or whatever) based on the signal mask. At least for Windows, one cannot mix sockets with other types of objects (files or whatnot). And, while I have not tried it, the docs seem to suggest that sockets for IPv4 and IPv6 may not be able to go to a single select call. All this makes matching event_handler instances to an appropriate event_dispatcher tricky and not portable. In other words, something that should be hidden from the user. The real complexity, though, comes when the number of objects gets large, in particular larger than a single call to select() can handle. This necessitated some load balancing logic to shuffle Selectable objects between threads, create new threads, cleanup extra threads, etc.. All of this is stuff that should only be written once! :) As a user of the library (again, at my work), I never have to worry about that mundane stuff. That is the job of the network library. And it scales pretty well. Though I haven't tested N*1000 simultaneous connections using drones across the network to simulate heavy CPU load, I have stress tested the library upto the limit of Windows XP Pro (not Server) and on Linux with N*1000 where N < 3, using lots of threads to generate the load. While all thread pooling and connection aggregation is managed behind the scenes, some of this could be exposed in an abstract manner to allow user code to influence the load balancing algorithm. This, I think, would be for only the very advanced user and not something to tackle initially. >> 1. Should the network library provide different choices >> of implementation to the user? For the most part, the >> platform will dictate the available solutions, so >> having the user decide would make their code >> non-portable. [my thought so far is no] >> >> 2. Would it be better perhaps to only provide behavior >> choices (sync, async, non-blocking) as part of the >> interface? [my thought is yes] > > I think two but not providing choices just support them > all automatically and efficiently. And give the user a > possibilty to plugin own implementations of the concepts. This is where our goals diverge I guess ;). I don't see any point in the user deciding these details, especially implementing their own concrete classes. And I do see it creating confusion amongst those that don't have the "Network API Guru" honor badge<g>. Because of the _long_ history of having to work directly at the socket/select/epoll layer, some of us aren't bothered by it (and some of us may even like it<g>). But this stuff is just unapproachable for anyone less than an advanced developer, is error prone at best and just plain tedious. Hard to tell how much I like select, eh? :) The interfaces I proposed provide a very clean and complete interface, IMHO<g>, and the implementation can be quite scalable (for those that need it to be) and I know it is extremely portable, even to non-socket based systems. Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

Re: async socket i/o [long]
by Don G 14 Apr '05

14 Apr '05

Hi Michel, > IOCP provides the most scalable way to do I/O on > Windows NT and later and it will blow the sock off > just about anything it minimizes context switching > by activaiting threads in FIFO order keeping a > single thread hot, and blocks dequeing completions > if there are more runnable threads on the port than > cpus in the machine. Any serious server application > should consider using it. But having a solid > portable select based mechanism to fall back on > could be used on any platform (supporting BSD > sockets at least). Sounds like it should, but it would be "easy" to measure down the line and verify. > Anyways maybe we should settle for the requirements, > before we decide the details, Agreed. The requirements are the hard part and important to agree upon. > but preferably I think the interface shouldn't rule > out an IOCP based implementation. There is nothing in the interface I proposed that would prevent an ICOP implementation. > And there seems to be a lot of different opinions on > what kind of servers and scalability requirements > the interface should provide. From simple blocking > to full blown asynch with best implentation on any > given plattform. Quite a diversity :) Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0