kc@cbnewsl.ATT.COM (keith.coulson) (03/16/90)
> Some thing like this is probably of interest to many. > Would you please make your re-write of libtsap and > tsapd using TLI publicly available? > > Making it part of the standard distribution could also > be a good idea. > Sorry, I'm not allowed to release the code because of conflicts with AT&Ts upcoming OSI offerings for SVR3/4. However, I can offer the following advice to anyone attempting to get ISODE working over TLI. 1. Re-writing libtsap was not that difficult. The documentation on libtsap gives a very clear definition. TLI and libtsap are both generic transport interfaces and the mapping between the two is fairly straightforward, the only exception being the receive side of connection establishment (see below). 2. libtsap and TLI use the terms 'listen' and 'accept' differently. i.e. TNetListen does not map to t_listen and TNetAccept does not map to t_accept. 3. The way TLI handles multiple connection requests (i.e. when a second connect request arrives on a stream before the first has been accepted or rejected) is difficult to handle within libtsap especially when forking a process for each request. This can be circumvented by modifying tsapd to be a TLI server (see the Network Programmers Guide for examples). In fact if you can live without static servers (I think quipu is a static server but hasnt been ported to SVR3 anyway) it is not necessary to implement TNetListen, TNetAccept and TNetFork. 4. xselect in libcompat also needs modfiying to use poll(). 5. I ran this over the starlan TP4. I used tsels of the form "hostname.filestore" for example and let the starlan directory server resolve network addresses. Good luck, Keith Coulson AT&T Bell Laboratories Summit NJ
sean@dsl.pitt.edu (Sean McLinden) (03/16/90)
In article <4612@cbnewsl.ATT.COM> kc@cbnewsl.ATT.COM (keith.coulson) writes: >> Some thing like this is probably of interest to many. >> Would you please make your re-write of libtsap and >> tsapd using TLI publicly available? >> >> Making it part of the standard distribution could also >> be a good idea. >> > >Sorry, I'm not allowed to release the code because of conflicts with AT&Ts >upcoming OSI offerings for SVR3/4. However, I can offer the following >advice to anyone attempting to get ISODE working over TLI. Clearly it's not your decision, but it is a bit of an oxymoronic policy which flies in the spirit of the "Open Systems" concept. Especially since it is a modification of code which was freely distributed. AT&T is rapidly becoming a company easy to dislike. But then, if it hadn't been for the taxpayers subsidizing the developments at Berkeley and the many institutions that evolved Unix into the operating system that it is, today, they'd still be selling telephones. But then what do you expect from a company that declares TCP/IP to be a reality when the rest of the world is talking OSI (they even had to buy their first implementation from a third party). To me selling anything below the 7th layer of OSI is like selling air for car tires or charging 10 cents for a cup of water; people will pay but you can't take a lot of pride in it. I mean, why not become imaginative and try selling applications, instead. Sean McLinden Decision Systems Laboratory University of Pittsburgh