TCP Functions and File handles

[WangoTango]

I must be missing something here.
This is a butchered up version of one of the examples, and there is no
error checking, but I think it might get the idea across.

If I open have multiple connections open to a server app using something
like this :
'------------------------------------------------------------
CASE %TCP_EVENT
SELECT CASE LO(WORD, CB.LPARAM)
CASE %FD_ACCEPT
temp_fnum = FREEFILE
TCP ACCEPT port_file AS temp_fnum
TCP NOTIFY temp_fnum, RECV CLOSE TO cb.hndl AS
%OPEN_TCP_EVENT
FUNCTION = 1
END SELECT
'------------------------------------------------------------

When the %OPEN_TCP_EVENT occurs CB.WPARAM is the Windows handle to the
socket, but it has no relationship to the temp_fnum I used to create the
socket in PB and, naturally, all the PB functions expect to be handed
the file number, not the Windows handle. I was hoping to stay away from
making an array or some kind of linked list to hold the info, especially
since the callback has the unique handle passed to it, *OR* am I missing
something obvious here?

[Wolfgang Enzinger]

Am Mon, 31 Oct 2011 16:10:45 -0400 schrieb WangoTango:

> When the %OPEN_TCP_EVENT occurs CB.WPARAM is the Windows handle to the
> socket, but it has no relationship to the temp_fnum I used to create the
> socket in PB and, naturally, all the PB functions expect to be handed
> the file number, not the Windows handle.

Just a short in the dark: doesn't OPEN HANDLE help in order to "translate"
a Windows handle into a PB handle?

Wolfgang

[WangoTango]

In article <14cp0ihqge8qs$.1lff2mypyk13c$.d...@40tude.net>,
we_u...@nurfuerspam.de says...

Yeah, *sort* of. From what I have tried, it doesn't work as advertised
with a TCP handle.

OPEN HANDLE CB.WPARAM FOR INPUT AS temp_file

Does work to the point that I can use the getpeername example (see
below) to get the IP address, but it fails when I actually try to read
data from the socket.
I have fiddled around with the MODE and ACCESS permissions a little, but
to no avail. It seems PB wants that original file number.
Unless there is some magic combination of mode and access that I haven't
tried.

'----------------------------------------------------------------------
' This takes a PB file number (as used with the TCP OPEN statement),
' and returns the IP address of the connected client connection as a
formatted string
'----------------------------------------------------------------------
FUNCTION TcpAddr_fnum(BYVAL s AS LONG) AS STRING
LOCAL sa AS SOCKADDR_IN
LOCAL l AS LONG
LOCAL b AS BYTE PTR
s = FILEATTR(s,2) ' Get WinSock2 socket handle
l = SIZEOF(sa)
getpeername(s, BYVAL VARPTR(sa), l)
b = VARPTR(sa.sin_addr)
FUNCTION = "IP=" + USING$("#_.#_.#_.#", @b, @b[1], @b[2], @b[3])
END FUNCTION

[Peter Manders]

In article <MPG.291a22747...@news.east.earthlink.net>,
Asga...@mindspring.com says...

There is a trick that might work. The help file says that FREEFILE
returns an Integer value in the range 1 to 32767. Windows messages can
be in the range of WM_USER to &HBFFF so you could try it this way:

Define %OPEN_TCP_EVENT as your highest message number. Add the file
number returned by FREEFILE to it like this:

uint = %OPEN_TCP_EVENT + temp_fnum
TCP NOTIFY temp_fnum, RECV CLOSE TO cb.hndl AS uint

When processing the message, test for a range of %OPEN_TCP_EVENT to %
OPEN_TCP_EVENT+32767. If it's in that range, substract %OPEN_TCP_EVENT
and there's your file number.

Declare uint as a WORD variable to make sure it gets added as an
unsigned integer. Rather than doing the addition in the TCP NOTIFY line.

--

Peter Manders.

Wise men talk because they have something to say,
fools because they have to say something. (Plato)

[WangoTango]

In article <MPG.291a930d9...@newszilla.xs4all.nl>,
use...@mandersDELETE.DELETEorg says...

I actually thought about something very similar at one point, but some
other issues have popped up that might make the whole thing a moot
point. I have noticed that if a client should just disappear, like a
power fail on their end, there is no CLOSE event triggered, even after a
LONG period of time, so I will have to assign some kind of inactivity
timer on a per socket basis, so if I have to do that, I might as well
man up and create a linked list of open sockets along with little
goodies like the original file number and a countdown timer for closing
dead sockets and so on. I was hoping to get off without doing much
"real" work.
This is kind of my first foray into a semi-serious app with PB. I
primarily used it as a way to cobble together utility apps that go along
with our embedded products as test routines, or examples on how to do a
certain function. I do 'C' day in and day out, and this has been a real
experience.
Anyway, since I have your ear, what's the deal with the TCP SEND
function? It looks as if sending string data is cool, but what about
binary data? Or, do I not understand what the function actually does?
If I have something like this :
TYPE cal_data
offset AS DWORD
data AS DWORD
cal AS DWORD
END TYPE

and I want to send a packet of those 12 bytes to a client or server, how
would TCP SEND know the length of the data, can it send the data? The
more I get into this the less I like the built in functions, or am I
missing something here too?

[Peter Manders]

In article <MPG.291b7e6ad...@news.east.earthlink.net>,
Asga...@mindspring.com says...

> Anyway, since I have your ear, what's the deal with the TCP SEND
> function? It looks as if sending string data is cool, but what about
> binary data? Or, do I not understand what the function actually does?
> If I have something like this :
> TYPE cal_data
> offset AS DWORD
> data AS DWORD
> cal AS DWORD
> END TYPE
>
> and I want to send a packet of those 12 bytes to a client or server, how
> would TCP SEND know the length of the data, can it send the data? The
> more I get into this the less I like the built in functions, or am I
> missing something here too?

TCP SEND just sends all the bytes in the string you send. You can use a
user defined type as argument for TCP SEND and it will send SIZEOF
(cal_data) bytes.

You can use TCP SEND to send binary data, but it's wise to put your data
in a packet, for instance starting with a LONG for "# bytes to follow",
a "type of data" indicator, the data itself, followed by a checksum,
followed by an LONG "end of packet" indicator.

At the receiving end you first read 4 bytes to determine the length of
the packet, then you know how many more bytes to read. If communication
happens to get out of sync, you can read bytes until the last 4 are the
"end of packet" indicator.

[WangoTango]

In article <MPG.291cd0ca3...@newszilla.xs4all.nl>,
use...@mandersDELETE.DELETEorg says...

> In article <MPG.291b7e6ad...@news.east.earthlink.net>,
> Asga...@mindspring.com says...
> > Anyway, since I have your ear, what's the deal with the TCP SEND
> > function? It looks as if sending string data is cool, but what about
> > binary data? Or, do I not understand what the function actually does?
> > If I have something like this :
> > TYPE cal_data
> > offset AS DWORD
> > data AS DWORD
> > cal AS DWORD
> > END TYPE
> >
> > and I want to send a packet of those 12 bytes to a client or server, how
> > would TCP SEND know the length of the data, can it send the data? The
> > more I get into this the less I like the built in functions, or am I
> > missing something here too?
>
> TCP SEND just sends all the bytes in the string you send. You can use a
> user defined type as argument for TCP SEND and it will send SIZEOF
> (cal_data) bytes.

I will have to try that.
I just used the socket command
send (alias as ssend) (socket, buffer, size, flags)
and went from there. Every time I tried something with the built in
command, it seemed to stop at the first 0 byte. Like it was trying to
use a NULL terminated string as the data type, but that could have been
the way I was calling the function too.

>
> You can use TCP SEND to send binary data, but it's wise to put your data
> in a packet, for instance starting with a LONG for "# bytes to follow",
> a "type of data" indicator, the data itself, followed by a checksum,
> followed by an LONG "end of packet" indicator.

That's fine *IF* you have control over what both ends of the pipe do.
Some of the time I have to go along with the spec of the device we are
talking to, and that may be any method. The nice thing is most of the
items I have to deal with are ours, or the TCP stack is a stripped down
version that doesn't handle fragmented packets, so you can be guaranteed
that all data will fit inside a single frame and there will be plenty of
time for each packet to reach the server before the next one is created.

>
> At the receiving end you first read 4 bytes to determine the length of
> the packet, then you know how many more bytes to read. If communication
> happens to get out of sync, you can read bytes until the last 4 are the
> "end of packet" indicator.

In the utility I am working on now, that shouldn't be a problem. Each
packet is built and flushed by the client so there is only one data
structure per packet, and that keeps it more like a UDP system with the
"guaranteed" delivery of TCP.

Anyway, thanks for your time, I will give the TCP SEND function another
try, but for now calling Winsock directly has gotten me out of the woods
for now. The rest is just fleshing out all the error checking and HMI
goodies.