Communication problem using TCP-IP vs NetBeui

[Agustin Tristan-Lopez]

I have a program for on line test scoring with two modules: administration (from a server) and exam (from terminal). The server has the exams and permissions and the list of terminals in a file where I keep the net address of each terminal (the file has, for instance: \\ip68\c, \\ip69\c, etc., the name is exactly as it appears in the net environment under windows 95/98 or NT).
The terminals have the exam module who communicates with the server, to do this I keep in the terminal the address of the server in a file (it contains the address such as: \\digital\server\c).
To interchange information and communicate, what I simply do is to read or write using the address. For instance in the exam program at the terminal I have:

ServerAddress$="\\digital\server\c"
ServerFile$=ServerAddress$+"MyExam.dat"
open ServerFile# for input lock shared as #1
'------
' the program is here
'------
close 1

this way I read from the server the exam information.

Similar form where the server has to read something from the terminal or send data

The program worked fine in several sites, but the last test we did in a school ´we´ve found many troubles:
some terminals could communicate all the time, other communicate at the beginning but suddenly they "close" the communication and it was impossible to continue linked with the server, even that the windows net said the terminal was available,
some others never could communicate. We had to shared the root and the directory of the application in the server and in the terminals, and the site responsible wasn´t very happy with this, but we couldn´t be successful.
After several trials, we saw that the protocol was TCP-IP and we´ve changed to NetBeui and from there everything was fine. Communication was in order, never close the link with the server, etc.
The questions are:
1) Is it normal that the way we´re sharing the files cause conflict under TCP-IP and not in NetBeui?
2) Is it normal that TCP-IP needs to shared all the disks (server and terminal) in order to send and receive files?
3) Do I need to change many things if I wish to have a better file exchange between server and terminals?

Regards.



------------------

[Tom Hanlin]

The protocol should be irrelevant. It may be that there was some configuration
error with the TCP/IP setup that was causing trouble.

------------------
Tom Hanlin
PowerBASIC Staff

[Agustin Tristan-Lopez]

Which kind of configuration errors for TCP-IP? Please give me some hints.

Thanks for the reply

------------------

[Tom Hanlin]

I have no suggestions on what kind of error. It's just that the network protocol
should have nothing to do with file or disk sharing capabilities. If changing
the protocol makes that kind of difference, it would seem that there was a
problem with how the protocol was configured.


------------------
Tom Hanlin
PowerBASIC Staff

[Agustin Tristan-Lopez]

Your opinion matches with mine, but how can I demonstrate to a rude client that his configuration has problems? is there a tool in windows to show the problems on the net and how the configuration has to be modified?

Thanks again

------------------

[Agustin Tristan-Lopez]

May you suggest a good book with deep explanations on how to configure in TCP-IP?

------------------

[Troy King]

Originally posted by Agustin Tristan-Lopez: I
have a program for on line test scoring with two
modules...

I'll venture a guess and suggest that the problem on
that network is name resolution, and that NetBeui fixed
the problem because it uses NetBIOS name broadcasts for
name-finding. The problem you may run into with NetBeui
is that it's not routable, so if the network grows, the
machines won't be able to talk to one another across a
router.

If the problem is indeed name resolution, I'm willing
to bet that whatever method they're using now for name
resolution is the problem. If you've got a WINS server,
I'll bet it's overloaded or goes down (same if it's DNS
rather than WINS). If the machines are using LMHOSTS
files for resolution and the problem is still
happening, then name resolution isn't the problem .

If you re-enable TCP/IP make sure you also enable
NetBIOS over TCP/IP. If you're using DHCP to dole out
the IP addresses, make sure you've changed the
appropriate parameters for name resolution (set node
type to 0x8 for WINS, and set the WINS and/or DNS
Server).

Of course this may not really be the problem, but
usually in cases where NetBEUI works and TCP/IP
doesn't, it is. There are other issues involved with
name resolution, but that's the quick ones.



------------------
Troy King
[email protected]

[Scott Turchin]

Troy hit a lot of this on the head but I'm going to add some more.
You wrote that trouble ended when TCP/IP was taken off?

First consider this, TCP/IP operates on subnets, if one IP address was taken from a different subnet then it's not going to see the other guys unless it goes to a router that routes to that subnet.

I don't have my subnet chart handy but as an example if one win95 machine had 192.168.10.24 as an IP address and another had 192.168.1.5 as an IP address it's likely they are not going to speak to eachother unless routed.

IPX would also work, Netbeui works because as Troy said it's spamming the network to make sure he's heard, much like that of a screaming child. (Can you tell that TCP/IP is my favorite protocol yet? *Grin*).

In a small classroom environment like that NetBeui is just fine, under 20 PC's and you probably won't have any issues on a 100mb network.

For more info on subnetting: http://www.learntosubnet.com/

Also note that if Win95/98 does not have File Sharing enabled you won't be sharing any files from that computer (you knew that)....and in addition if these machines are logging into a domain then you can set the file sharing at user level as well.

And then note if you are using 3com 3c905B-TX's it's always a favorite for people to use the built in 3c905XL driver in NT, or 95 and SOMETIMES it even works....this is a BIG issue in the real world and is solved by downloading the right driver....




Scott


------------------
Scott

[Bud Durland]

And then note if you are using 3com 3c905B-TX's it's always a favorite for people to use the built in 3c905XL driver in NT, or 95 and SOMETIMES it even works....this is a BIG issue in the real world and is solved by downloading the right driver....

Or by chucking it completely & putting in an Intel card. I don't even let the disk for a 3Com NIC near my servers. But that's another thread...

------------------

[Fred Oxenby]

If I undertand you correctly, your "server-app" is writing a file
to a client "\\ip68\c\YourExam.nnn" and this is not successful?
---
One reason in a TCP/IP-only network could be that the TCP/IP-setting
on this PC has no reference to its "GATEWAY".
Check what router this pc is using and fill in the ip.address of this router
under Tab "gateway" in this PC-s TCP/IP settings



------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se