brian@ucsd.EDU (Brian Kantor) (08/13/89)
Geoff's model of the interface between CNews and NNTP is correct if you have only one NNTP feed, but it does not correctly address the environment that I and some of the other internet news administrators have - we each have multiple NNTP news feeds which are CONTINUOUSLY delivering news articles. If we were to batch those articles and then process them periodically, we would have wasted significant amounts of network resources transferring duplicate articles. (BTW, our goal is to thus cut the average news propagation delay from hours to minutes, if not seconds.) For example, I am often offered the same article from tut, ucbvax, and rutgers within a minute or two of each other. Had I not posted the article when I first got it, I'd have accepted and transferred two redundant copies, which is a waste of network and temporary disk space. As it is, I occasionally accept an article that I'm already in the process of receiving from another site, but luckily that window is small. Cnews is a good thing. But it has one or two assumptions that don't fit the environment in which some of us live. And so we have to change it. Free software is often like that. After all, you didn't pay to have it customized for you. And remember that Cnews was developed at a site that was (so I'm told) primarily uucp-connected at the time that the design and major development was done. Besides, you can steal some of the really good ideas from Cnews and retrofit them into Bnews if you want - that way you get a news system that you already understand with some of the really nifty improvements that Geoff and Henry have come up with. Brian Kantor UCSD Postmaster & Chief News Weenie brian@ucsd.edu BRIAN@UCSD ucsd!brian "UUCP is dead." - Peter Honeyman, Feb 1989.
brian@ucsd.EDU (Brian Kantor) (08/13/89)
Geoff's model of the interface between CNews and NNTP is correct if you have only one NNTP feed, but it does not correctly address the environment that I and some of the other internet news administrators have - we each have multiple NNTP news feeds which are CONTINUOUSLY delivering news articles. If we were to batch those articles and then process them periodically, we would have wasted significant amounts of network resources transferring duplicate articles. (BTW, our goal is to thus cut the average news propagation delay from hours to minutes, if not seconds.) For example, I am often offered the same article from tut, ucbvax, and rutgers within a minute or two of each other. Had I not posted the article when I first got it, I'd have accepted and transferred two redundant copies, which is a waste of network and temporary disk space. As it is, I occasionally accept an article that I'm already in the process of receiving from another site, but luckily that window is small. Cnews is a good thing. But it has one or two assumptions that don't fit the environment in which some of us live. And so we have to change it. Free software is often like that. After all, you didn't pay to have it customized for you. And remember that Cnews was developed at a site that was (so I'm told) primarily uucp-connected at the time that the design and major development was done. Besides, you can steal some of the really good ideas from Cnews and retrofit them into Bnews if you want - that way you get a news system that you already understand with some of the really nifty improvements that Geoff and Henry have come up with. Brian Kantor UCSD Postmaster & Chief News Weenie brian@ucsd.edu BRIAN@UCSD ucsd!brian
geoff@utstat.uucp (Geoff Collyer) (08/13/89)
Brian Kantor: >Geoff's model of the interface between CNews and NNTP is correct >if you have only one NNTP feed Note that the C news NNTP mods were written for jarvis.csri.toronto.edu which gets at least two NNTP feeds from off-campus (from mailrus and rutgers). The news administrators there (and I'm told at U. of Montreal) refused to run NNTP if it insisted on running an rnews for every incoming article, which is exactly analogous to the performance disaster of B news unbatching. Running an inews per article would be even worse. >If we were to batch those articles and then process them periodically, >we would have wasted significant amounts of network resources transferring >duplicate articles. You can override a few default settings (*without* changing any C code!) in server/batch.c to process batches every so-many seconds or every so-many bytes in order to achieve as small a window for duplicates as you wish; it's your CPU and your disk. The important thing is to not repeat the mistakes of B news unbatching by spawning an rnews for every incoming article. A further improvement would be to restrict the number of simultaneous nntp daemons to some locally-chosen number. The CSRI folk have occasionally expressed a desire for this. >Cnews is a good thing. But it has one or two assumptions that >don't fit the environment in which some of us live. Thanks, we like to think that we have provided tools so that people can do just this. People have described to us some really inventive ways in which they have combined our programs (e.g. running expire only from newsrun when free space gets low), so by one measure ("a tool is a program that people use in ways never imagined by its authors" - Brian Kernighan?), we are providing tools. >And remember that Cnews was developed at a site that was (so I'm told) >primarily uucp-connected at the time that the design and major development >was done. In fact we put a lot of late development work into hooks for NNTP, so this isn't really relevant any more. >Besides, you can steal some of the really good ideas from Cnews and >retrofit them into Bnews if you want Now this I've *got* to see. The reason I wrote relaynews was because B rnews was such a ball of hair that I couldn't get it to unbatch without invoking a process per article. There are global variables all over B news and lots of places think it's okay to just print an error message and exit when anything goes wrong; this doesn't cut it for unbatching. > "UUCP is dead." - Peter Honeyman, Feb 1989. I asked Peter a few months ago if he really said that, and his reply was essentially `yes, but I should have said "mailer science is dead"'. Certainly our uucp connection to citi over the Internet works just fine. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
henry@utzoo.uucp (Henry Spencer) (08/13/89)
In article <1894@ucsd.EDU> brian@ucsd.edu (Brian Kantor) writes: >... we each have multiple NNTP news feeds which >are CONTINUOUSLY delivering news articles. If we were to batch >those articles and then process them periodically, we would have >wasted significant amounts of network resources transferring >duplicate articles. (BTW, our goal is to thus cut the average news >propagation delay from hours to minutes, if not seconds.) There is a fundamental tradeoff here which simply can't be escaped: efficient processing of large amounts of news requires amortizing setup overhead over more than one article, while lightning-fast propagation requires processing each article as it arrives. You just have to decide where the balance point lies for you. With volume in the multiple MB, many of us have no trouble deciding that we don't *care* whether news gets through in hours or minutes. We certainly don't care enough to dedicate an increasingly large fraction of an already-busy system... which is what it takes if you really want to cut response time. If you have good-sized machines to spare, we'd be happy to pay the shipping to have them sent up here, where they will be used for real work instead. :-) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
Makey@LOGICON.ARPA (Jeff Makey) (08/13/89)
In article <1989Aug13.071802.5187@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >There is a fundamental tradeoff here which simply can't be escaped: >efficient processing of large amounts of news requires amortizing setup >overhead over more than one article, while lightning-fast propagation >requires processing each article as it arrives. I can think of two ways to have the best of both worlds: (1) merge nntp and rnews into one program and (2) change rnews into a daemon. I like the second method better. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
rick@uunet.UU.NET (Rick Adams) (08/13/89)
Wouldn't the nntp problem be solved if nntp could directly exec the unbatching program instead of going though rnews? ---rick
steve@nuchat.UUCP (Steve Nuchia) (08/13/89)
In article <1989Aug13.071802.5187@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >efficient processing of large amounts of news requires amortizing setup >overhead over more than one article, while lightning-fast propagation The solution I'm working on is to run a server process as a monitor supervising the LIBDIR data structures. It gets set up at boot time and is free to cache whatever it (I) finds expedient. You trade swap space for time, but with news running most of the time anyway the swap space is spent. This soluiton is partially motivated by a desire for smarter and easier-to-administer propagation algorithms, but it wins speed too. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
flee@shire.cs.psu.edu (Felix Lee) (08/14/89)
In <1895@ucsd.EDU>, brian@ucsd.EDU (Brian Kantor) writes: > If we were to batch those articles and then process them > periodically, we would have wasted significant amounts of network > resources transferring duplicate articles. We're running C News with NNTP feeds from rutgers, ukma, gatech, and husc6. For the last day or so, we've received 36 duplicates out of 1800 articles. This seems acceptably small to me. Running news on a fast machine (a Sun 4/280) probably helps the matter. If NNTP were to batch IHAVEs, then duplicates may become silly. Hmm. How about have nntpd lock Message-IDs from the time a sendme is requested until the batch is processed by rnews? Like the L<foo@bar> files that B News used to create. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
tneff@bfmny0.UUCP (Tom Neff) (08/14/89)
In article <1895@ucsd.EDU> brian@ucsd.edu (Brian Kantor) writes: > ... (BTW, our goal is to thus cut the average news >propagation delay from hours to minutes, if not seconds.) Hey, I thought conventional net.wisdom was that this was a Bad Idea. The slower propagation of news is supposed to encourage careful followups and discourage little chat wars. No? -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
brian@ucsd.EDU (Brian Kantor) (08/14/89)
Felix Lee mentions 36 duplicates out of one day's 1800 articles. Clearly that's an acceptable number. Last Friday we received about 3500 articles; about 350 were duplicates. Some of that is due to the fact that we have a couple of uucp newsfeeds, thus I don't know how many of the 350 were nntp only duplicates. Loose thought: NNTP could insert received message-ids into a temporary cache that it would use to reject duplicate offerings as well as checking the history file. The cache entry would be purged after a day. Then you can batch the articles themselves. In fact, the easy way to do this in the B-news environment is to write a simple stupid little 'nntprnews' that just stuffs the article into /usr/spool/news/.rnews and stores the message-id into a DBM database, along with the timedate as an ASCII long. Doing it this way makes purging (nntpexpire?) the temporary database real simple, and allows you to batch the actual posting. Or instead of 'nntprnews', just make it a new subroutine in nntpd - it's small and simple enough.... I haven't tried it - hell, I just thought it up while writing this followup. This would probably work real well with Cnews too. - Brian
jerry@olivey.olivetti.com (Jerry Aguirre) (08/14/89)
In article <1989Aug13.071802.5187@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >There is a fundamental tradeoff here which simply can't be escaped: >efficient processing of large amounts of news requires amortizing setup >overhead over more than one article, while lightning-fast propagation >requires processing each article as it arrives. You just have to decide Is there a reason that NNTP can't insert the batch headers and pass the news to the processing portion (recnews?) via a pipe instead of a file? In that way a single setup overhead would cover the entire NNTP session. By using a pipe instead of a temporary file the delay between transmission and appearing in the history file could be minimized. Jerry
geoff@utstat.uucp (Geoff Collyer) (08/14/89)
Jerry Aguirre: >Is there a reason that NNTP can't insert the batch headers and pass the >news to the processing portion (recnews?) via a pipe instead of a file? >In that way a single setup overhead would cover the entire NNTP session. The C news version of nntpd generates the #! rnews batch headers and copies the incoming articles into a spool file in the incoming-batch queue. Every so many bytes or seconds, and at the end of each session, the current spool file is handed to newsrun and thus relaynews. This is fast enough that recently, after jarvis.csri.toronto.edu had been down for a long weekend, I watched nntpd-newsrun-relaynews race with expire: free i-nodes were low on jarvis's news partition and even with the expire niced to -1 (that's preferred niceness for you csh users), nntpd-newsrun-relaynews was creating files faster than expire was removing them, with the difference being roughly one file every few seconds (yes, the partition ran out of i-nodes eventually). This is fast enough for me. There just doesn't appear to be enough setup overhead in the nntpd-newsrun-relaynews processing to matter, at least on jarvis, which does have a non-vanilla news configuration. Sending incoming articles directly into relaynews via a pipe from nntpd would save a small amount of setup overhead but would introduce some new problems (or features, depending on your point of view): since only one relaynews can run at a time, only one nntpd could be actively receiving at a time, unless you introduce substantial buffering in nntpd's data segment, which introduces the risk of dropping articles in the case of a crash. Having at most one nntpd actively conversing at any time would prevent nntpd from accepting duplicates, though, which might well be the best solution to minimise duplicates. >By using a pipe instead of a temporary file the delay between >transmission and appearing in the history file could be minimized. By adjusting the age and size batch-file thresholds in the C nntpd, one can already have fine control over the size of that window (our defaults are 300k bytes or 5 minutes, since we'd prefer to trade off larger window size for better performance, and we usually hit the size limit (or end of session) well before the age limit). Henry and I talked about some sort of hook to let nntpd directly tell relaynews or the history file itself "put this message-id in history as a partially-completed entry and the entry will be completed later when the article arrives", but we haven't done anything more than talk about it. We would really like to sell our changes back to the owners of NNTP so that we can concentrate on the non-NNTP news software, and eventually (one hopes soon!) on other matters altogether, such as the work we are paid to do. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (08/15/89)
>(2) change rnews into a daemon. I > I came to the same conclusion. Relaynews should just be sitting there all all the time waiting for rnews to feed it something. -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
henry@utzoo.uucp (Henry Spencer) (08/17/89)
In article <9636@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >I came to the same conclusion. Relaynews should just be sitting there all >all the time waiting for rnews to feed it something. You have to think about when caches get flushed: other things rely on the disk being fairly up to date, and flushing everything out is a non-trivial part of the current startup/shutdown overhead. And there are some thorny locking issues involved. One aspect of it is quite fundamental: there can only be one relaynews running at a time if file updating is to be done properly, and so you need a way to feed that process from multiple sources -- this is very hard to do portably. Could be done, but it's not quite as simple as it looks. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
steve@nuchat.UUCP (Steve Nuchia) (08/17/89)
In article <1989Aug16.182527.24840@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: [re: relaynews as a daemon] >You have to think about when caches get flushed: other things rely on the >disk being fairly up to date, and flushing everything out is a non-trivial >part of the current startup/shutdown overhead. And there are some thorny >locking issues involved. In an nntp environment, which is what I think we should all be planning future development work for, the disk files cease to be so significant. There are good low-overhead ways to implement single-process database software (record management library level), e.g. paper from decwrl for which I don't have a handy citation. >One aspect of it is quite fundamental: there >can only be one relaynews running at a time if file updating is to be This is one very good reason to make it a daemon. It is also desirable to have only one copy to ensure that real users can get a cycle in edgewise. >done properly, and so you need a way to feed that process from multiple >sources -- this is very hard to do portably. Very hard? It is nontrivial only if you want it to be simultaniously portable, low latency, and high throughput. My usual trick is to write for a simple message passing interface and provide implementations for sysV IPC, sockets, and named pipes -- and plain files if necessary. The multiple sources then just need to all use the right library. >Could be done, but it's not quite as simple as it looks. Is anything ever as simple as it looks? If one goes looking for complexity in a system one will find some. I still think a long-running daemon is the way to go. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
henry@utzoo.uucp (Henry Spencer) (08/19/89)
In article <13705@nuchat.UUCP> steve@nuchat.sccsi.com (Steve Nuchia) writes: >In an nntp environment, which is what I think we should all be >planning future development work for... Although NNTP is good stuff, remember that there are a *lot* of sites that are still connected by good old UUCP, and this isn't likely to change any time soon. Joining "interactive" networks that can do NNTP usually costs money; linking up by UUCP is often free. > ...the disk files cease to >be so significant. There are good low-overhead ways to implement >single-process database software... Except that none of the news readers know about them. The news readers don't have to have information that is right up to the latest second, but it's necessary to flush in-core information periodically unless you want to fix *all* of the news readers to talk to the database process. There are *lots* of news readers, many more than you think. Changing all of them won't be fun. Like it or not, the disk files remain important because they are a de-facto standard interface. >... I still think a long-running daemon is the way to go. You may well be right, but somebody is going to have to put in a significant amount of effort to find out; it's not a five-minute hack. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (08/21/89)
>>I came to the same conclusion. Relaynews should just be sitting there all >>all the time waiting for rnews to feed it something. >You have to think about when caches get flushed: other things rely on the >disk being fairly up to date, and flushing everything out is a non-trivial >part of the current startup/shutdown overhead. And there are some thorny >locking issues involved. One aspect of it is quite fundamental: there >can only be one relaynews running at a time if file updating is to be >done properly, and so you need a way to feed that process from multiple >sources -- this is very hard to do portably. > The locking/concurrency problem is basically the same one that exists now. You put a lock on input to relaynews that processes have to wait for if busy. True, the IPC stuff isn't going to be very portable. I agree about the cache flushing - but the big advantage is that you do things when needed (every n minutes or n articles), not automatically for every batch. -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
jerry@olivey.olivetti.com (Jerry Aguirre) (08/24/89)
In article <1989Aug16.182527.24840@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >done properly, and so you need a way to feed that process from multiple >sources -- this is very hard to do portably. I am beginning to seriously wonder if writing "portable" code is a good idea. (Note, no smiley attached.) There seems to be a steady stream of ideas that would be really great but are "hard to do portably". While part of the "ball of hair" that news 2.11 became was do to evolutionary modification I think that the better part of it is due to trying to maintain compatability with dozens of environments. I mean it has ifdefs for BSD, 4.2, 4.3, SysV, Pyramid, Xenix, HP, and more. As a case in point I added code to do forks instead of execs when processing batches. It worked for most environments but broke for a few people with strange STDIO libraries. More IFDEFS and other arcane modifications were added to the code. Right now I would be afraid to change any part of 2.11 news because it would certainly break in someone's environment. So, do we write for the "lowest common denominator"? Use temporary files for IPC? Worry about address space for PDP11s and small model PCs? No standard file locking? I can't see us getting clean high performance code that way. Or do we stay with a spagetti of define, ifdef, else that needs a guru or AI to configure. (Is my rindex fast?, Do I even HAVE rindex?) It isn't even always a matter of OS compatability. There are sites out there running with 10 times the CPU power and 1/20th the disk space that I have. Naturally the word "optimize" means something entirely different to them. What I am contemplating is totaly separate versions of code for the major versions of Unix. That is, someone would maintain a BSD version, someone else would maintain a SysV version, yet another an Xenix version, etc. If a bug fix or improvement can be ported from one to the other then great. Maybe some of the code, say for parsing headers and handling control messages, could be common. But lack of portability should not hold back all the versions. Of course this means extra work because more than one version would have to be maintained but there are certainly enough sites now to justify it. (What the heck, we have 3 separately maintained versions already!) On the other hand beta testing would not requre 20 carefully selected sites so the total work might actually be less. Comments? Jerry Aguirre
karish@forel.stanford.edu (Chuck Karish) (08/24/89)
In article <47046@oliveb.olivetti.com> jerry@olivey.UUCP (Jerry Aguirre) wrote: >In article <1989Aug16.182527.24840@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>done properly, and so you need a way to feed that process from multiple >>sources -- this is very hard to do portably. >I am beginning to seriously wonder if writing "portable" code is a good >idea.... >What I am contemplating is totaly separate versions of code for the >major versions of Unix. That is, someone would maintain a BSD version, >someone else would maintain a SysV version, yet another an Xenix >version, etc.... >But lack of portability >should not hold back all the versions. It doesn't hold back all the versions now. Henry's article, quoted above, was an invitation for someone else to implement a feature that might only be useful for some systems. >Of course this means extra work because more than one version would have >to be maintained but there are certainly enough sites now to justify it. >(What the heck, we have 3 separately maintained versions already!) >On the other hand beta testing would not requre 20 carefully selected >sites so the total work might actually be less. We'd need a real standard to define a base level of compatibility. How much fun would this `My news is the One True News' discussion be with twenty principal participants instead of three? Compare the amount of effort that's necessary to maintain the kermit archives to the maintenance that news requires. Kermit works on more architectures and has to deal with more severe incompatibilities, so it's worth the trouble. Why ASK for that sort of grief with news, which could stay basically portable under the present system? Chuck Karish karish@mindcraft.com (415) 493-9000 karish@forel.stanford.edu
kayvan@mrspoc.Transact.COM (Kayvan Sylvan) (08/25/89)
In article <47046@oliveb.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes: > Newsgroups: news.software.b > Summary: Is "portability" too expensive? > Date: 24 Aug 89 05:58:22 GMT > Reply-To: jerry@olivey.UUCP (Jerry Aguirre) > Organization: Olivetti ATC; Cupertino, Ca > > [...] > > What I am contemplating is totaly separate versions of code for the > major versions of Unix. That is, someone would maintain a BSD version, > someone else would maintain a SysV version, yet another an Xenix > version, etc. If a bug fix or improvement can be ported from one to the > other then great. Maybe some of the code, say for parsing headers and > handling control messages, could be common. But lack of portability > should not hold back all the versions. This is absolutely and positively a bad idea. We do not need fragmentation of the code. The major versions of Unix are almost identical in many respects and getting closer to that ideal every day. > Of course this means extra work because more than one version would have > to be maintained but there are certainly enough sites now to justify it. I don't think there's too much justification for the extra work that would be entailed by this. It is not *that* difficult to do the proper configuration for your particular system. Granted, this could be made easier perhaps by better design and documentation. Perhaps a better idea might be to have the core system dependant functions in one module or library that would be linked in according to various system defines. Something like the GNU Emacs process of generating the actual makefile from a template makefile that is fed through the preprocessor... This could arrange for unixv.c, xenix.c, bsd.c, sun.c, etc. to be compiled and linked according to some configuration constants. This might even cut down the total number of #ifdefs and such throughout the rest of the code. ---Kayvan -- Kayvan Sylvan @ Transact Software, Inc. -*- Los Altos, CA (415) 961-6112 Internet: kayvan@Transact.COM -*- UUCP: ...!{apple,pyramid,mips}!mrspoc!kayvan
henry@utzoo.uucp (Henry Spencer) (08/26/89)
In article <47046@oliveb.olivetti.com> jerry@olivey.UUCP (Jerry Aguirre) writes: >So, do we write for the "lowest common denominator"? Use temporary >files for IPC? Worry about address space for PDP11s and small model >PCs? No standard file locking? I can't see us getting clean high >performance code that way... Uh, we managed it for C News. We use no funny IPC mechanisms, run quite successfully in small address spaces, use link(2) for locking (which is fully portable), and get clean high-performance code at the end of it all. We have a submission in to the winter Usenix of a paper talking about how we do it. >... else that needs a guru or AI to configure. (Is my rindex fast?, >Do I even HAVE rindex?) If you don't have rindex, you don't get asked that question. If you do, it matters whether it is fast or not, and there is no way we can figure it out for you. Which flavor of Unix you have is irrelevant; the answer is *very* machine-specific and vendor-specific. The current version of build adds "(okay to guess)" on that question. >What I am contemplating is totaly separate versions of code for the >major versions of Unix... Talk about maintenance nightmares... Geoff and I refuse to abandon portability, even if it means a bit more work. (The amount of work should lessen in coming years, as POSIX compliance and ANSI C compliance become widespread.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu