Author Topic: Using TCP in the uTasker project  (Read 83923 times)

Offline mhoneywill

  • Full Member
  • ***
  • Posts: 173
    • View Profile
Re: Using TCP in the uTasker project
« Reply #30 on: February 24, 2009, 12:36:13 AM »
Mark,

I've just used the demo code at the head of this post to test how to handle TCP and I found a number of typo's, I'm mentioning them here so you can amend the code listing so others don't have the same problems I did. The errors are as follows

1. The Code below has an extra }

    case TCP_EVENT_CLOSED:
        fnTCP_Listen(Socket, ++usTestPort, 0);                    // go back to listening state on next port number
        break;
        }
 
should be
   
    case TCP_EVENT_CLOSED:
        fnTCP_Listen(Socket, ++usTestPort, 0);                    // go back to listening state on next port number
        break;


2. In the following code test_message->tTCP_Header should be test_message.tTCP_Header
   
    case TCP_EVENT_DATA:
        if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4))) {
            uStrcpy((CHAR*)test_message.ucTCP_Message, "Hi!!");
            if (fnSendTCP(Socket, (unsigned char *)&test_message->tTCP_Header, 4, TCP_FLAG_PUSH) > 0) {
                return APP_SENT_DATA;
            }
        }

    should be

    case TCP_EVENT_DATA:
        if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4))) {
            uStrcpy((CHAR*)test_message.ucTCP_Message, "Hi!!");
            if (fnSendTCP(Socket, (unsigned char *)&test_message.tTCP_Header, 4, TCP_FLAG_PUSH) > 0) {
                return APP_SENT_DATA;
            }
        }

3. In the start-up code you suggest using
    USOCKET Test_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTestListener);
    This should be
    USOCKET Test_socket = fnGetTCP_socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTestListener);
    Note the lowercase s in fnGetTCP_socket

Looking at tcpip.h it seems the case of the function words after a _ symbol is a bit random, for example

extern USOCKET fnGetTCP_Socket(unsigned char ucTos, unsigned short usIdleTimeout, int (*listener)(USOCKET, unsigned char, unsigned char *, unsigned short) );
extern USOCKET fnGetUDP_socket(unsigned char ucTOS, int (*fnListener)(USOCKET, unsigned char, unsigned char *, unsigned short, unsigned char *, unsigned short), unsigned char ucOpts);
extern USOCKET fnReleaseUDP_socket(USOCKET SocketHandle);
extern USOCKET fnReleaseTCP_Socket(USOCKET TCPSocket);

I hope the above helps

Cheers

Martin


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using TCP in the uTasker project
« Reply #31 on: February 24, 2009, 11:46:58 AM »
Hi Martin

Thanks, I have corrected these.

I didn't make the third change since fnGetTCP_Socket() with capital matches with the header file and the routine in tcp.c.

It is a shame about the mixture between use for capital and small - I won't change anything just yet because it may lead to problems. (Perhaps a #define fnGetTCP_socket() fnGetTCP_Socket() would make it case insensitive...?)

Regards

Mark

Offline syakovlev

  • Newbie
  • *
  • Posts: 20
    • View Profile
Any plans to have AUTOIP ?
« Reply #32 on: March 26, 2009, 09:21:17 PM »
So far search for AUTOIP returns 0 results.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using TCP in the uTasker project
« Reply #33 on: March 26, 2009, 09:55:15 PM »
Hi Sergei

I don't know much about AUTO-IP but I did think that the SW to do this was running on a PC in the network together with SNMP capabilities of managed switches.

As to what the embedded device needs to do, I think it just needs to request its IP address using a BOOTP reguest.

Do you have a specific requirement?

Regards

Mark

Offline syakovlev

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Using TCP in the uTasker project
« Reply #34 on: March 26, 2009, 10:29:02 PM »
Hi Mark,

A plan is to assign "Reasonable" default IP address to an instrument before shipment.
We were thinking about using private address in the range 169.254.x.x.
In this case user will be able to connect to the instrument before getting static IP address from his sysadmin.
And it looks like AUTOIP support is needed in case <"Reasonable" default IP address> will happen to be in
conflict with some other instrument which is also using address in range 169.254.x.x.
Our instrument will need new address dynamicly "self-assigned" in range 169.254.x.x.

Best regards.
Sergei.

Offline aaronlawrence

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Using TCP in the uTasker project
« Reply #35 on: April 30, 2010, 01:03:52 AM »
Mark,
can you either "pin" this topic so it stays at the top, or link to it from the documentation page?
I came back to try and find it and could not, even knowing it was there in the general forum.
Thanks.
(unfortunately the code explorer still doesn't have some of this stuff)

Offline hossain2

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Using TCP in the uTasker project
« Reply #36 on: May 27, 2010, 09:53:56 AM »
With the problem above, not connecting, I was trying it on the simulator. I now copied the code into the 52233 flash. And it worked fine, without modifying any code.
Within the call back routine above 'static int listener(SOCKET Socket, unsigned char prevent, unsigned char *Luci_Data, unsigned short unsporting)' is 'Luci_Data' a pointer to the data read in, and 'unsporting', The number of characters?

Offline hossain2

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Using TCP in the uTasker project
« Reply #37 on: May 27, 2010, 09:57:44 AM »
On thing to note is a difference here between when working with the simulator and working on the target. When the client tries to connect in the initialization of application.c the simulator can send immediately. On the target it generally takes a few seconds for the Ethernet link to become ready and so it takes a little longer before it all works.

Offline hossain2

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Using TCP in the uTasker project
« Reply #38 on: May 27, 2010, 09:59:20 AM »
This is logically the reason why the use of TCP is a frequent question and frequent discussion topic in private mails. It is also a reason why this document, which is long overdue, should soon be made available.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using TCP in the uTasker project
« Reply #39 on: May 27, 2010, 11:49:19 AM »
Hi

Concerning the listener parameters, these are described in the following document:
http://www.utasker.com/docs/CodeDoc/fnGetTCP_Socket.htm

All TCP functions are described formally in the code documentation: http://www.utasker.com/docs/Code.html -> see TCP/IP -> TCP.C

Regards

Mark


Offline hossain

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Using TCP in the uTasker project
« Reply #40 on: May 29, 2010, 10:17:12 AM »
OK, i think A successfully sent message can also fail to arrive at the destination due to a transmission error for example - it may arrive too but the ack could get lost instead. In this case the transmission should be retried after TCP has detected the timeout - or after ARP has resolved the destination IP address.
thanks
« Last Edit: May 29, 2010, 11:40:21 PM by mark »

Offline aloft

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Using TCP in the uTasker project
« Reply #41 on: June 27, 2010, 06:24:45 AM »
Hi Mark,

I'm trying to implement a ftp client but I'm running into some problems.  After I send the USER <username> on the control socket, I'm getting a TCP_EVENT_PARTIAL_ACK back that doesn't seem to get handled properly.  From your thread, it sounds like this shouldn't happen. 

Any ideas what I'm doing wrong.

Thanks,

TW

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using TCP in the uTasker project
« Reply #42 on: June 27, 2010, 01:42:24 PM »
Hi

Generally you shouldn't get a PARTIAL_ACK event when a simple TCP socket is used unless multiple frames are sent without first waiting for an ACK. This would be an error case since a simple TCP socket must wait for an ACK before sending the next frame.

However there does seem to be a case just after a connection when there is a repetition that a PARTIAL_ACK event can be received with a length of zero. Generally when partial ACKs are ignored  this doesn't disturb - otherwise by ignoring when the length is zero is a strategy (my development version no longer calls the event when the length is zero to avoid any potential confusion).

Is this partial ACK received consistently? Please post a WireShark recording since the reason for it may be visible there.

Regards

Mark

Offline aloft

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Using TCP in the uTasker project
« Reply #43 on: June 30, 2010, 04:36:08 AM »
Hi Mark,

My mistake on this.  It was apparent when looking at this with Wireshark that my breakpoint was causing the PARTIAL_ACK event. 

I see another problem where I'm not responding with an ACK - but I think I should be sending one unless I misunderstand the process.  I'm getting an ACK in my Listener routine after I send the USER <username>.  Since the TCP_EVENT_ACK just breaks out of the switch statement, I should return the APP_ACCEPT which should generate an ACK, correct?

I sent my screenshots and code as well as a wireshark trace in a separate email.

Thanks,

TW

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Using TCP in the uTasker project
« Reply #44 on: June 30, 2010, 09:01:20 AM »
Hi

I was not able to answer to your email addresses - something seems to be blocking it or my sender-address and returning the mails. I did send a personal message though with the following answer:



I don't see any TCP problems (all ACKs are visible in frames and there is no ACK to an ACK). All that I see is that you are not getting an answer from the server when you send "USER lbmwelldata2" but this is probably due to the fact that "\r\n" is missing at the end of the string so that the server knows that the input is complete. The server should then return a request 331 for the password.

Regards

Mark