TCP server

[georpo]

Hi All,

I want to transfer data between a PC and a PIC tcp server, I am using PIC18F67J60. The transfer rate will be not more than 5 bytes/sec.

I tried ex_13b which worked well but only in my LAN. It hangs after some time when I test it through the internet. I did some tests with the suplied TCP client.exe and with hyperterminal winsock.

I use this for sending data to the PC:

[gpsmikey]

I have not played with that code, but a couple of things to keep in mind.

- Many ISP's will block the ftp (and other) ports to their users (you can ftp out, but they don't want you setting up ftp servers on their network).

- Another potential pothole in the road (based on experience ) is that when you close a port, you tell the operating system you are done with it. The OS may not get around to actually closing the port for some period of time and as such, if you try to open that port again very soon after closing it, you get errors about the port being in use (took me a while to track that one down and understand the problem).

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[andrewg]

I haven't done this sort of long-lived connection, but have you tried calling TCPIsConnected() and re-connecting if it isn't? If your comms is 'bursty' a computer somewhere may be dropping an apparently idle connection.

Alternatively, have you considered UDP packets? You need to be aware that they aren't reliable and may be dropped, but they're typically pretty good and you can always implement simple flow control of your own.
_________________
Andrew

[georpo]

Thanks for the reply guys.

The problem is that the connection holds for ever when used in my local area network. why should there be a difference through the internet?

[andrewg]

Your local LAN will be far more reliable and far faster than the Internet. Just because you've been lucky up to now on your LAN doesn't mean you'll stay lucky tomorrow...
_________________
Andrew

[Wayne_]

I doubt very much that an ISP will block FTP but anyway.

With the internet (no idea what your connection is) there is more chance for a delay/error/disconnection.

If you have allowed the PIC only 1 socket, the PC will connect to this and transmit/recieve data. When there is a disruption the PC will retry and then close the socket and try to open a new one. The PIC with it's 1 socket, still open will wait either indefinately or until it times out (I assume it is timing out for you).
This is where the delay comes from.

Now you can configure the PIC for more than 1 socket, but if you are using the code supplied from CCS (which I have been), there are bugs in it, especially for multiple sockets. I have managed to fix most for my app, It did turn out that I was using an older version of the CCS (microchip converted) code but I don't think they have fixed it.

You could reduce the timeout making sure it is long enough for your interval.

Or it could be something else.

[georpo]

I have allowed 5 sockets for the PIC connections. The client software hangs but the PIC thinks it is still connected. There is no error there. Maybe TCP was no meant to be used for this purpose. Are there any suggestions-examples for my case?

I do not want to use UDP because I do not want to drop any bytes in the way. I need to transfer 5 byte packets to the PIC and back with 200mS delay between each byte. It is a very low rate and I thought it would be very easy. Should I try UDP just to see if it hangs or not?

Keep in mind that for client software I used:
a) the suplied TCP client.exe
b) My VB application using winsock
c) hyper terminal using winsock.

In all cases the comunication stops after some time when used through the internet.


Thanks

[andrewg]

I think UDP would work well, even though you're going to have to implement buffering, sequencing and acknowledgements. UDP can be made reliable!
_________________
Andrew

[georpo]

First results with ex12.c UDP example:

"Could not bind socket. Address and port are already in use."

[andrewg]

MAX_UDP_SOCKETS must be defined for the number of UDP ports you're using. Also, you can't use the same socket that you might already be using for TCP.

eg here's cut-down NTP code from one of my projects:

[georpo]

Andrew,

I am afraid I cannot follow your example because my experience on this field is limited. For now I will have to stick with the CCS udp example until I understand how it works but unfortunatelly the CCS UDP example does not work! It does not connect with the UDP.exe and I do not get any error messages. Just that the PIC is listening...

It would be great if you could provide a working example to start with.

Thanks

[andrewg]

OK, break it down into steps. Transmitting first. Call this function on the PIC, say once a second (sorry, I also missed clearing the MAC above):

[georpo]

I tested this with wireshark, it sends the 3 bytes correctly.
I think that the problem is in the UDP.exe.

I did not know that you can set the receiver's IP in UDP transfer.
The PIC should be act as a server, meaning that it does not know who (which IP) will connect and receive the data.

Now how can I receive these bytes from the PC side?

Thanks!!

[andrewg]

[georpo]

and something strange...

I use wireshark but I see UDP traffic only if I use ports 1024 and 1025.
I tried other port numbers but no luck.

The PIC seems to send the packets (the magjack led flashes) but I do not see them in wireshark.