TCP Socket comm problem

Leon Puth

Hi All.

i run windows service , one each on port 8081, 8082 thru 8090. Each port has multiple external incoming connections with data send / receive. Each windows service is identical c#.net code across all ports.

one port, 8083, behaves differently: data sent to external is lost. We can see it on packet sniff on 8083 going out but external does not receive it.

if i put same message to same external on any other of the ports, it works.

firewall and antivirus is identocal on all ports, so why thsi problem. 8083 has most connections, so am i over utilizing it?

thanks

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Leon Puth7y ago
thank you Logesh

im not using wcf, rather a windows service receiving tcp over http. im able to establish the connection and send receive data on some devices, but others just dont et the response, as if the tcp packet is completely lost, probably due to the socket overlaoding. at peak i record 300+ connections.

thanks
Logesh Palani7y ago
A service endpoint WCF must always supply the ABC - Address, Binding, Contract. You only define the binding in your config - and that's exactly what the error message says - your address is null. So your config fragment should look something like
        "MyDownloadSvcClient">

                address="http://localhost:8888/YourService"
                binding="basicHttpBinding"
                contract="IYourServiceContract" />



The Address defines where the service endpoint lives, at what address it's available to the outside world. If you have no address, then the service cannot talk to the outside where. It's there WHERE of your service. If you host your service in IIS, using a *.svc file, you might be leaving this address empty, since the service address is determined by the server and virtual directory where the *.svc file lives - but you still need to supply an address="" entry to your service / tag!

The Binding defines how the service interacts - what protocol, what security settings etc. - it's the HOW of your service.

And the Contract in the end defines (through a service contract, typically an interface in your service definition) what service methods (functions) are available to a caller. You must supply a contract, otherwise the caller has no way of knowing what methods he can call on your service. It's the WHAT of the service.