|
From: Chuck Crayne on 20 Apr 2008 16:07 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 20 Apr 2008 16:21 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 20 Apr 2008 16:24 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 24 Apr 2008 15:02 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 24 Apr 2008 16:03
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. |