µTasker Forum > µTasker general

Using TCP in the uTasker project

<< < (2/10) > >>

neil:
Hi Mark,
 I quickly tried to add a client, and have it connecting to my server application, but without any luck.  Could you let me know what I am doing wrong? Here is the small code.. (It just simply connects, no sends/receives)

USOCKET Test_socket;

static int fnTestSocket(USOCKET Socket, unsigned char ucEvent, unsigned char *ucIp_Data, unsigned short usPortLen)
{

    switch (ucEvent)
   {
      case TCP_EVENT_CONREQ:                                             
      case TCP_EVENT_CONNECTED:
      case TCP_EVENT_CLOSE:
      case TCP_EVENT_ACK:
      case TCP_EVENT_ARP_RESOLUTION_FAILED:
      case TCP_EVENT_PARTIAL_ACK:
         break;
      case TCP_EVENT_REGENERATE:
      case TCP_EVENT_DATA:
         if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4)))
         {
         }            }
         break;
      case TCP_EVENT_ABORT:
      case TCP_EVENT_CLOSED:
         break;
   }
    return APP_ACCEPT;
}


Within the 'fnApplication(..)', making it the last bit of code within 'if (!iAppState)':

Test_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)20, fnTestSocket);
fnTCP_Connect(Test_socket, "192.168.0.184", 10000, 0, 0); //my server address and port...

The connection is never made (all done within simulator), and the call back function always gets called with switch value of '9'.

I have my server application running in debug, so I can tell when a connection is made.
Regards
Neil

mark:
Neil


--- Quote ---Does this mean its not possible to have 2 or more clients connecting to a server?
--- End quote ---

What I meant was that it is no two clients from the same IP address may have the same port number when connected to the same server port number. This is also the same restriction for the clients at the other end of the connection when we are acting as server.
So there is no problem with having multiple clients connected to a server.

I should be more precise. This is not an implementation restriction but a simple TCP connection rule:
A TCP connection is determined by two parameters; IP addresses at the two ends and Port numbers at the two ends.
For example Device A is at 192.168.0.3 and device B is at 192.168.0.4 in a local network
Device A and B have servers running on Port 80 (HTTP port).

Now Device A and Device B both have clients which connect to the server.
Let's say there are 2 connections from each. The clients will use a 'random' port number when connecting for the first (the uTasker uses a dynamic port range between 49152 and 65535) and each subsequent connection then uses the next port number.

Therefore the following 4 connection may exist, which are defined by the unique connection pairs (IP and Port):
Connection 1 (Client at A connected to server at B)
    192.168.0.3:50672 <-> 192.168.0.4:80
Connection 2 (Client at A connected to server at B)
    192.168.0.3:50673 <-> 192.168.0.4:80
Connection 3 (Client at B connected to server at A)
    192.168.0.3:80 <-> 192.168.0.4:52819
Connection 4 (Client at B connected to server at A)
    192.168.0.3:80 <-> 192.168.0.4:52820

As you can see. The server uses the same port but there is always a different client port number. Therefore each TCP connection is unique since the port pairs are never the same.

Regards

Mark

mark:
Neil


--- Code: ---fnTCP_Connect(Test_socket, "192.168.0.184", 10000, 0, 0); //my server address and port...
--- End code ---

The first problem that I see is in the use of the IP address.
The uTasker project doesn't store IP addresses as strings but rather as arrays.

Therefore you need to spefify your IP address like this :


--- Code: ---unsigned char ucMyIp[IPV4_LENGTH] = {192,168,0,198};
fnTCP_Connect(Test_socket, ucMyIp, 10000, 0, 0); //my server address and port...
--- End code ---

This may then work.
What the previous version probably did was send the connection request to 31.39.32.31 which would then be directed to your default gateway and sent out onto the internet.
If you are receiving TCP_EVENT_ARP_RESOLUTION_FAILED (this will occur after about 4..5 seconds) it would imply that you don't have a local gateway.

Note that you can also activate "USE_TIME_SERVER" in config.h to see how it program operates. It is a client example and there are a number of timer servers which it attempts to contact until one if successful. The time server will send one message (with the time - surprise surprise) and close the connection.

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 initialisation 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.

Another point to note is that a client connection attempt often causes an ARP resolve to be initialted. This is because the address of the destination is not yet in the local ARP table. A server will invariably have the IP address already in the table since it was refreshed there as it received the connection attempt (SYN) from the remote client. For the user this is in fact totally transparent since TCP handles it itself when connecting. It is however possible that during an active connection the ARP entry times out (due to non activity or a network with high activity causing it to be flushed). In this case the ARP resolve will be automatically started but the listener will need to be able to resend the last message via the TCP_EVENT_REGENERATE.

fnSendTCP() will return the number of bytes transmitted. If it has to start an ARP resolution it will however return NO_ARP_ENTRY. In this case the user can also prepare for the regeneration event which is expected. Should instead TCP_EVENT_ARP_RESOLUTION_FAILED be received, it means that the connection partner is no longer reachable - it has maybe turned off in the meantime and so the connection could be terminated.

Regards

Mark




neil:
Hi Mark,
  The above worked fine, thanks, I can now connect to the server application.  I will soon start looking at sending/receiving side.

Many Thanks
Neil

neil:
Hi mark,
  After succesfully connecting to my server application (Windows based), I thought I would send some data. I want to send the following block of data, which my server application understands as a command:

After a connection is made, within the call back function I insert the code to send to my server, as follows:

unsigned char Buff[10];
//call back function
static int fnTestSocket(USOCKET Socket, unsigned char ucEvent, unsigned char *ucIp_Data, unsigned short usPortLen)
{
   TCP_MESSAGE test_message;

    switch (ucEvent)
   {
         case TCP_EVENT_CONNECTED:
                Buff[0]=0;
                Buff[1]=5;
                Buff[2]=233;
                 Buff[3]=5;
                Buff[4]=32;
                          if (fnSendTCP(Socket, &Buff[0], 5, TCP_FLAG_PUSH) > 0)
                   return APP_SENT_DATA;
                         break;

                    ....
             }


The above gets sent, but when I debug my server application, the above values are not received, there are 5 characters sent, but not the above.

Can you point me to where I am going wrong?

Regards
Neil

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version