Author Topic: Writing a TCP socket  (Read 3529 times)

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Writing a TCP socket
« on: March 26, 2008, 06:22:42 PM »
 Is it possible to return the number of bytes written when
calling =fnSendTCP() ? The end of fnSendIP() contains the following code
which I wouldn't think would do it. It looks like it returns <= 0 on an error.
 I am porting some linux type net code to run in uTasker that would loop writting the socket until all the data went out. I see the data buffer passed in  fnSendTCP() must also contain an uninitialized TCP header area ,which isn't included in the length. If  fnSendTCP()  doesn't
return the actual byte count that was sent, what would be a safe
max that I could use to break up the data ?

Code: [Select]
    fnWrite(Ethernet_handle, dat, usLen);      // add the pay load
    return (fnWrite(Ethernet_handle, 0, 0));   // transmit the  EHERNET frame


« Last Edit: March 26, 2008, 06:30:15 PM by johnr »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: Writing a TCP socket
« Reply #1 on: March 26, 2008, 07:26:12 PM »
Hi John

I am not sure that it will be possible to interface exactly like this. In fact fnSendTCP() will either be able to transmit or not (the only times that it will not be able to send is when it needs first to resolve the destination address (return NO_ARP_ENTRY) or when all transmit buffers are full (which I haven't actually seen happening...).

Therefore it will never send partical data.

I think that you will need to either:
- send each frame after receiving an ACK event from the previous
- or, copy the data to a buffered TCP socket or TELNET type socket, in which case you can pass as much data as there is space for in the TCP buffer. Any remaining data will then have to wait until there is space again (using the TX_FREE event).

See and for more details.



Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: Writing a TCP socket
« Reply #2 on: March 27, 2008, 04:13:17 PM »
Thanks Mark, the links cleared it up a bit. I'm familar with the linux and
windows socket abstractions, which are higher level APIs.
 Our application is basically half duplex in nature. One side sends a data packet and the other responds with an ack data packet. Most packets are only a few hundred bytes in length. The largest packet we would receive would be 1550 data bytes, which is only sent at initialization to download params. 
 I'm still trying to decide whether to use the simple non-buffered or
buffered interface. I'm looking at the smtp code as a starting
point. We don't need the throughput of the buffered interface, so we can save memory, at the expense of more API compexity.  Eventually it will make sense  ;D