Tcp socket, not receiving data


#1

Hello,

I’m working on a program using a TCP server sockets. I have another application (pc-based) that can connect to this socket and send data etc.
Now there is a problem receiving data from the pc application.

When I connect to the TCP server, I get the WIP_CEV_OPEN event, than the WIP_CEV_WRITE. So that’s OK.
But when I send data from my pc application to the TCP server, it doesn’t fire up an event.

When I close my socketconnection on the pc application, I receive a WIP_CEV_READ event, this event has all the data that was send from the pc application.
Then I receive a WIP_CEV_PEER_CLOSE event, which closes the connection.

But how can I get a WIP_CEV_READ event when I send the data, and NOT when I close the socket from the client side (pc application)?

Thank you very much


#2

someone? :blush:


#3

What’s your module’s address? Unless you specifically paid for the option, GPRS providers only give you local IP addresses, i.e. the module can contact computers, but not the other way around.


#4

The computer can contact the module, because I get the ’ WIP_CEV_OPEN ’ event, and also the ’ WIP_CEV_READ ’ event. But the read event is only reached when I close the socket on my computer, and not when I actually SEND the data.

How can I force the module to generate a WIP_CEV_READ event when data is send to the module?

greetings


#5

It would be rather surprising that something as fundamental as read events notification were broken and nobody noticed before you… Here are a couple of suggestions:

  • activate IP traces (in TMT, activate NET traces, number 16). This will show you IP data, so you’ll know when data actually arrives to the module.
  • try to use your PC program against another PC, to make sure that it actually sends data before shutdown
  • try to send a significant volume of data (a dozen KB) and make sure that really nothing arrives: many strange networking behaviors are linked to some form of caching, on terminal nodes or on intermediate nodes on the route.
  • check whether the module writes succesfully

#6

Yes - there could also be “buffering” effects, where something is waiting for a (resonably) “full” packet, rather than sending large numbers of very small packets. Obviously, when the link is requested to close, it will immediately send whatever data it has “buffered”…


#7

Yes I also thinks it’s a “buffering” effect. But how can I solve that in the module? I’ve tried to set the "WIP_COPT_RCV_LOWAT " … but that doesn’t work either :frowning:

thanks


#8

First, by checking whether it’s actually one, and where it happens if it does. Cf. my post above.


#9

As fft said, “think” isn’t enough - you need to confirm.

If the bufferning is not in the module itself, then there’s nothing the module can do about it!

You’d have to look for options in the sender…