From: Chuck Crayne on
On Sun, 20 Apr 2008 07:52:58 GMT
Frank Kotler <fbkotler(a)verizon.net> wrote:

> This example shows memory for the parameter structure allocated in
> static memory... "sparms rd 6"... that's in ".bss" I guess? Could go
> on the stack, as "tin cans and string" suspected...

If the program has only one connection to manage, then the socketcall
parameters could indeed go on the stack. However, the example is taken
from a multiplayer game server which multitasks the players using
the connect system call. As each player has his own stack, it makes
more sense for the communications manager to use global variables.

And yes, there are socket calls which use more than three parameters,
as for example:

mov eax,[ebx+pinfd] ;socket file descriptor
mov [p0],eax ;socket file descriptor
mov [p1],ecx ;receive buffer
mov [p2],edx ;length of buffer
mov [p3],0 ;no flags
mov eax,__NR_socketcall
mov ebx,SYS_RECV
mov ecx,sparms
syscall

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: Chuck Crayne on
On Sun, 20 Apr 2008 06:45:59 -0700 (PDT)
tin.cans.and.string(a)gmail.com wrote:

> Ah. I'm using NASM.

So am I, these days, but I wrote the program at a time when NASM seemed
to be dead. If I had written it in NASM, I would have used a structure,
such as:

struc sparms

p0: resd 1
p1: resd 1
p2: resd 1
p3: resd 1
p4: resd 1
p5: resd 1

endstruc

Incidentaly, I no longer remember why I defined six parameters, as the
highest I actually used was p3.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: Chuck Crayne on
On Sun, 20 Apr 2008 06:52:43 -0700 (PDT)
tin.cans.and.string(a)gmail.com wrote:

> If any of you know of a treasure trove of ASM-level
> documentation on sockets programming, I'd love to get my grubby mitts
> on it.

Ask a couple more question here, get a demo running, and you'll be
qualified to write such documentation.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: Evenbit on
On Apr 20, 9:52 am, tin.cans.and.str...(a)gmail.com wrote:
> On Apr 20, 1:52 am, Frank Kotler <fbkot...(a)verizon.net> wrote:
>
> > But at the "sys_call" level, there's really only one - "mov eax, 102"
> > - ebx takes the "command", or "subfunction", "SYS_SOCKET",
> > "SYS_BIND", "SYS_CONNECT", etc. and ecx takes a pointer to
> > a "parameter structure". The meanings of the parameters differs
> > depending on which "subfunction" we're doing, but (for some reason)
> > we recycle the same "structure".
>
> Righto - and there's a dearth of information available on the web
> concerning how to make use of the socketcall function at the assembly
> level.

If you can find a tutorial on how to do it from C (or other language)
-- it would give you a good start.

I imagine that the process would not be too different from how to do
it in Windows. There is a simple "instant message" example here:

http://flatassembler.net/examples/quetannon.zip

We can use the loop-back address {127.0.0.1} for testing during
development.

Nathan.
From: tin.cans.and.string on
On Apr 24, 1:02 pm, Evenbit <nbaker2...(a)charter.net> wrote:
> If you can find a tutorial on how to do it from C (or other language)
> -- it would give you a good start.
>
> I imagine that the process would not be too different from how to do
> it in Windows. There is a simple "instant message" example here:
>
> http://flatassembler.net/examples/quetannon.zip
>
> We can use the loop-back address {127.0.0.1} for testing during
> development.
>
> Nathan.

Thank you, Nathan. I'll take a look at that code and see if it
clarifies anything for me.