TCP/IP Question

I'm working on a program that communicates with other instances of the same program running on other PCs.

It's coded using TCP/IP and Windows Sockets. PCs are connected using a switch and the switches are backboned to other switches.

Communication works well with other PCs on the same switch, but becomes inconsistent when receiving packets from PCs on other switches.

Adding switches and PCs degrades communication.

I didn't write the program and I'm not an expert on Sockets programming but I have to find a solution.
Whether it's improving the existing TCP code or some other method of communication altogether.

What I'm looking for is suggestions on what to look for in the existing code. I know sockets programming well enough to find my way around it and debug it.

If it's coded correctly, doesn't TCP/IP have guaranteed delivery? Is degradation to be expected when the number of PCs increases? Is there anything that can be done to improve/overcome this problem?

Who is Participating?
jhanceConnect With a Mentor Commented:
>>How will the SENDER know?

There are two possibilities and usually BOTH should be used:

1) A "broken" socket will return an error to the application that is using it.  Have you ever been using a network application and seen the "connection reset by peer" message?  This is one indication that the network has failed.  There are other possible messages.

2) Any "robust" network client/server setup will include whatever mechanism is needed to get the confirmation needed.  For example after each network send the receiver can acknowledge receipt.  If the sender doesn't receive an error but doesn't get a confirmation, it can resend.  This is NOT handled at the TCPIP protocol level but is handled by the application itself.

>>Increase the bandwidth of the network,

If your network is 10M bps, then that is the maximum bandwidth.  Under NO circumstances can you pump more than 10M bps over such a network.  If you upgrade your hardware to 100BaseT, now you have 10X the bandwidth.

>>split the network into subnets,

Without subnets, every host on the network sees all the traffic.  If A and B are talking, then there is a limit on communications betwen C and D since they share the same "road" so to speak.  But if the network is segmented via routers and switches (as opposed to hubs) then C and D never see A -> B traffic since these machines are on different subnets and the router or switch doesn't pass traffic for B onto C and D's network.  So A and B as well as C and D each have full access to their own networks.  It's only when traffic crosses segments that bandwidth is lost due to this and by careful design of the segments and routes, you can minimize this.

>>add additional network connections between heavily loaded segments ...

If A and B talk to each other a lot, it may be advantageous to add a 2nd network port to each machine and install a dedicated or additional network link between the two.  You can then change the routing priority so that A and B only talk to each other via their "private" link and all other hosts talk to either of them via their public ports.  This is quite commonly done when you have multi-tier server systems where there may be a large amount of traffic between a web server and a database server that implement a system.  Since it is intended that the web server and the database server will be communicating a lot, it may make sense to dedicate a network path for their exclusive use.

trishmAuthor Commented:
BTW: I prefer improving the existing sockets code versus changing the communication method altogether. (If it's possible).
You frame the question in generalities (degrades, becomes inconsistent) but you ask for specific recommendations.  Not really likely...

>>doesn't TCP/IP have guaranteed delivery?

No, that's impossible.  But the SENDER will know if the connection failed if using TCP vs. UDP.

>>Is degradation to be expected

Of course.  You have an increasing number of consumers (i.e. client PCs) competing for a finite resource (the available network bandwidth).  You will get performance degradation with greater demands on the network.

>>Is there anything that can be done to improve/overcome this problem

Lots of things.  Increase the bandwidth of the network, split the network into subnets, add additional network connections between heavily loaded segments, choose a different network technology that give better high load performance (i.e. token ring).  There are entire book on this stuff...
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

TCP/IP is a stream based connection. The stream will either get to the recipient or else, as JKR says, the connection will be broken and both parties will know about this.

However one major error frequently made is assumptions when sending/recieveing blocks of data. Specifically it is wrong to assume that send/recv will either fail or successfully send/recv all your required data. Let me clarify...

When sending large amounts of data over a poor connection it is likely that the internal send buffers become full, in which case send() will return how many bytes it actually managed to send (or even 0). You must then wait and call send again to send the remaining data.

Similarly when recieving data over a poor connection recv can only return data that has actually arrived (obvious I know). Hence recv() may return less bytes than you expect. Again you should wait and then recv some more.

 PC1 sends 5000 bytes with send()
 PC2 calls recv() and yet only gets 4000bytes
 PC2 examines the data and realises it is incomplete.
 PC2 then waits a bit and calls recv() again to get the remaining 1000 bytes


trishmAuthor Commented:
Thank you both for your informative comments!


You're right. I did ask general questions. I wasn't 100% sure about what to ask.

>>But the SENDER will know if the connection failed ...

How will the SENDER know?

>>Increase the bandwidth of the network, split the network into subnets, add additional network connections between heavily loaded segments ...

Would you elaborate a little bit on each of these?


>>The stream will either get to the recipient or else,
the connection will be broken and both parties will know about this.

How will both parties know that the connection has broken?

trishmAuthor Commented:
Great! Thank you very much!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.